What I Wish I Knew Before My First Hackathon

The Mistake Every First-Timer Makes

My first hackathon, our team of four opened our laptops at 9:01 AM and started coding immediately. We had a vague idea (something with maps and local events) and figured we’d work it out as we went.

By hour six, we had three separate codebases that didn’t connect, no shared understanding of what the app was supposed to do, and a heated argument about whether the backend should use Firebase or Express. We presented a half-broken demo that the judges politely sat through.

The team next to us spent the first two hours in a conference room with a whiteboard. No laptops. They came out with a clear plan, split up the work, and built a polished demo that won second place.

I’ve since done a dozen more hackathons and judged a few. The pattern is always the same: teams that plan first, win. Teams that code first, struggle.

The First Two Hours Are Everything

A 24-hour hackathon sounds like a lot of time. It isn’t. By the time you subtract meals, fatigue, debugging, and the inevitable “nothing works” panic at 2 AM, you have maybe 14-16 productive hours.

Spending two of those hours planning feels expensive. It’s actually the cheapest investment you’ll make. Here’s how to use that time.

Pick a Problem, Not a Technology

“Let’s build something with computer vision” is a technology looking for a problem. “Students waste 20 minutes finding open study spaces on campus” is a problem looking for a solution.

Judges evaluate whether your project solves a real problem. Start there. Technologies are tools. Pick them after you know what you’re building.

Sketch the User Flow

Grab a piece of paper and draw the screens. Not wireframes, just boxes with words. “User opens app, sees a map, taps a building, sees available rooms, books one.”

This takes ten minutes and prevents the single biggest hackathon time-waster: building features that don’t connect into a coherent experience. Every screen should lead to the next. If you can’t sketch the flow, you don’t understand the product yet.

Agree on the Demo Story

This is the tip most hackathon guides miss. Your demo is 3-5 minutes. That’s it. Plan the demo before you build.

Write down the exact story you’ll show the judges. “We open the app, we’re a student looking for a study space, we see the map, we tap the library, we see room 204 is free, we book it, done.”

Now build exactly what you need for that demo to work. Nothing more. If a feature doesn’t appear in the demo story, it doesn’t get built.

Split the Work Cleanly

With a clear plan, you can divide work without stepping on each other. One person does the frontend. One does the backend. One handles the data layer or API integrations. One prepares the presentation and handles design.

Agree on the interfaces between each piece early. “The backend will return a JSON array of rooms with name, building, and available boolean.” That’s enough for the frontend person to start building without waiting.

During the Hackathon

A few things I’ve learned the hard way:

Get something working end-to-end early. A ugly, hardcoded version of the full flow is more valuable at hour eight than a beautiful, polished version of one screen. You can polish later. You can’t debug integration issues at 3 AM.

Fake what you can’t build. Your AI model doesn’t need to actually work for the demo. Hardcode the responses if you run out of time. Judges are evaluating the idea and the execution of the overall experience, not whether your ML pipeline is production-ready.

Stop coding one hour before presentations. Use that hour to practice the demo, fix the flow, and prepare for questions. I’ve seen technically brilliant projects lose because the demo was disorganized and confusing.

Commit your code regularly. Nothing is worse than losing work because someone’s laptop crashes at midnight. Push to GitHub every hour at minimum.

What Judges Actually Look For

Having sat on the judging side, I can tell you: we’re not impressed by complexity for its own sake. We’re looking for three things:

Does it solve a clear problem? Can you explain who this is for and why they need it in one sentence?
Does the demo work? A smooth, working demo of a simple idea beats a broken demo of an ambitious one every time.
Did the team understand what they built? Can you answer questions about tradeoffs, limitations, and what you’d do next?

All three of those things come from planning, not from writing more code.

Your First Hackathon Checklist

Before you write a line of code:

Define the problem in one sentence
Sketch the user flow on paper
Write out the demo story (what you’ll show judges)
Agree on the tech stack as a team
Define the interfaces between each person’s work
Set a “code freeze” time for one hour before demos

Do this, and you’ll already be ahead of 80% of the teams in the room. The best hackathon project isn’t the most technically impressive. It’s the most coherent. And coherence comes from planning.