What you'll learn
Quick Answer
Pick something you can demo in two minutes and finish in half the available time. Decide the demo script before you write code. Most teams fail on scope and integration, not on ability, and a working small project always beats an ambitious broken one.
Why go at all
The prizes are the least valuable part. What you actually get is a deadline that forces you to finish something, which is a rare experience for students whose projects usually drift; practice at building with people you have not worked with before; and a project you can talk about that has a story attached.
You also learn where your gaps are, quickly and without consequences. Discovering that you cannot deploy under time pressure is much better learned at a hackathon than during an internship.
You do not need to be good yet. First-time teams are the majority at most college hackathons, and organisers expect it.
Choosing an idea: the two-minute rule
Whatever you build must be demonstrable in about two minutes, because that is roughly what judging gives you. Work backwards from that.
Write your demo script before writing any code. Literally the sentences you will say and the clicks you will make. If the script requires a feature, build it. If a feature does not appear in the script, it is optional — and at hour twenty, optional means cut.
Good hackathon ideas share a shape: one clear user, one clear problem, one visible moment where the thing works. "Upload a photo of your prescription and get the medicine names read out" has a moment. "A comprehensive healthcare management platform" does not, and cannot be shown in two minutes.
Aim to finish the core in half the available time. Everything runs late, and the second half will be consumed by integration and by problems you cannot predict.
Splitting the work without blocking each other
The classic failure is four people who each finish their part at hour twenty-two and discover the parts do not fit together.
Avoid it by agreeing the interface between components in the first hour — the exact shape of the data passing between frontend and backend. Write it down, even roughly. Then each person can work against that agreed shape rather than against code that does not exist yet.
Two practices that pay for themselves:
- Fake data early. The frontend should work against hardcoded sample data from hour two, so it is never blocked waiting for the backend.
- Integrate continuously. Merge every few hours, not once at the end. The first integration always breaks something; you want that discovered at hour six, not hour twenty-three.
Assign one person to own the demo — the presentation, and making sure the demo path works end to end. This is a real job, and teams that skip it discover at judging that the flow breaks on step three.
What to cut first
Almost everything students build first is not needed for a demo:
- Authentication. Unless the project is about auth, hardcode a logged-in user. Nobody is impressed by a signup form, and it costs hours.
- An admin panel. Nobody asks to see it.
- Responsive design. You will demo on one screen. Make that screen good.
- A database, sometimes. If the demo does not need persistence, an in-memory list is enough and removes a whole category of setup problems.
- Edge cases and validation. You control the demo input.
This feels wrong to anyone who has been taught to build things properly, and it would be wrong for a real product. A hackathon build is a prototype whose only job is to demonstrate an idea within a deadline. Judges know that, and they are judging the idea and the demo, not your error handling.
The demo, which decides everything
Teams with worse projects routinely beat teams with better ones, purely on the demo. It is not unfair — the demo is the only thing judges actually see.
- Open with the problem, in one sentence. Judges have watched twenty pitches and need context immediately.
- Show the thing working before explaining how. Lead with the moment it works.
- Rehearse it at least twice. Out loud, with the laptop, on the real setup.
- Record a backup video. Wi-Fi fails at hackathons with remarkable consistency.
- Do not apologise. "We didn't get time to finish X" draws attention to a gap nobody had noticed. Present what exists.
Expect "what would you do next?" and have a real answer. It signals you understand the problem beyond what you managed to build, which is exactly what judges are probing for.
Surviving the night
Sleep at least a few hours. Teams that stay up for the full duration write code at hour twenty that they spend hour twenty-two deleting, and then demo badly because they cannot form sentences. Sleeping in shifts is strictly better than not sleeping.
Eat properly, drink water rather than only energy drinks, and take a short walk when stuck — the number of bugs solved on a five-minute walk is genuinely high.
Afterwards, spend one hour cleaning up the repository and writing a README while it is fresh. That turns a rushed weekend into something you can put on your GitHub profile and talk about in interviews. Most teams never do this, and the project quietly disappears.