A hackathon is equal parts sprint and marathon. You get a problem statement, a team and a deadline, and the clock does not care that it is 4 a.m. The good news: first-timers win more often than you would think, because judges reward a clear idea that works over an ambitious one that does not.
Before the event
- Form a balanced team: someone who builds the interface, someone on the backend, and someone who can pitch
- Set up your laptop the night before: editor, runtime, a starter template you know
- Read the rules on eligibility, team size and what counts as pre-built code
Hours 0 to 3: pick the right problem
Do not choose the hardest problem statement. Choose the one where you can show a working demo in 18 hours and still have time to polish it. Write down the single sentence you want the judges to remember, and build only what serves it.
Hours 3 to 18: build the spine first
- Get the core flow working end to end, even if it is ugly
- Commit often, so a bad change never costs you an hour
- Only then add the features that make the demo memorable
Hours 18 to 24: the demo is the product
Stop adding features. Rehearse a three-minute demo with a real example, prepare a backup recording in case the Wi-Fi fails, and make sure every teammate can explain one part of it.
Judges remember a demo that worked. They forget the feature you were still debugging.
Eat the meals, take a short nap if the venue allows it, and talk to the mentors. They are there to help, and they often sit on the judging panel.
