How to win your first hackathon

Your first hackathon can feel like walking into an exam where everyone else studied a different syllabus. Teams talk fast, someone already has a design file open, and you’re still reading the problem statement. The good news: most hackathons are not won by the smartest coder in the room. They’re won by teams that pick a sharp problem, build a small thing that works and explain it well.

Here’s a plan you can actually follow.

Before the event

1. Pick the right hackathon

For a first attempt, choose an event with a theme you already care about and a format you can handle. A 24-hour online event during exam week is a bad idea; a weekend event in your city after your first internals is much better. On HackathonFinder you can filter by city, online or offline, theme, team size and deadline, and the calendar makes clashes with college commitments easy to spot.

2. Read the rules twice

The judging criteria tell you exactly what to aim for. If impact and presentation carry as much weight as technical depth, plan your time that way. Check eligibility, team size limits, whether you can use code written before the event and what you must submit: a repo, a video, a deck or all three.

3. Prepare your setup, not your project

Most events don’t allow pre-built projects, but they do allow preparation. Install your tools, make sure everyone can push to a shared repo, keep a starter template ready and decide who handles frontend, backend, design and the pitch. Still short of people? Post on the Team Finder board.

During the event

4. Spend the first hour on the problem

Resist the urge to start coding straight away. Write one sentence: we help a specific person do a specific thing because of a specific pain. If you can’t fill that in, you don’t have an idea yet. “An app for farmers” is vague. “A voice-first flow that tells a small farmer today’s market price for one crop” is something judges can picture.

5. Build the demo path first

Decide the one flow you’ll show on stage, then build only what that flow needs. Login screens, settings pages and admin panels can wait or be faked. A demo that works end to end for one scenario beats a half-finished platform with ten features.

6. Use checkpoints

Check in every few hours: what’s done, what’s blocked, what we’re cutting. Cutting scope early is a skill, not a failure. In the last quarter of the event, stop adding features and focus on making what you have stable.

7. Sleep a little

Tired teams write silly bugs and mumble through pitches. Take turns resting, eat proper food and keep water nearby. A short nap at 3 a.m. can save you two hours of debugging later.

At the finish line

8. Practise the pitch out loud

Run through the pitch at least three times before you present. Know who says what, keep a screen recording of the demo in case the Wi-Fi fails, and put your strongest moment, the live demo, in the middle rather than at the end where you might run out of time. Our three-minute pitch guide on this blog goes deeper on this.

9. Submit early

Upload portals slow down in the final minutes. Submit a working version an hour before the deadline and update it later if the platform allows.

Win or not, collect the real prizes

Not every first hackathon ends with prize money in ₹. But you walk away with a project for your resume, a public repo, new friends and a much better feel for working under pressure. Write down what went well and what you’d change, then pick the next event. Save a few upcoming ones to My hackathons so you can track each one from saved to registered to submitted.

A simple rule: the goal of your first hackathon is to finish. The goal of your second is to win.