Hall of HacksHow to win a hackathon
We’ve read through dozens of grand-prize and finalist projects to build this archive. The winners almost never have the most code or the fanciest tech. They share a handful of habits, and you can copy every one of them.
1. Solve a real problem, ideally one you actually have
The most convincing projects fix something the team genuinely needed fixed. When one team showed up to a hackathon with nowhere to sleep, they built bots that phoned real hotels and booked them a room that night. Pick a problem you can describe to a stranger in one breath. If it’s a problem you have, you’ll demo it like you mean it.
2. Make the demo actually work, live
Most hackathon demos are faked or run on canned data. The ones that win do something real in the room. A project that actually delivered 100 pounds of food to real shelters over the weekend is impossible to argue with. Build the one thing that works for real, even if everything around it is held together with tape.
3. Pick an idea people understand in one sentence
If a judge can’t repeat your idea to the next judge, it loses. “You FaceTime your own computer and tell it what to do” needs no explanation. Neither does “real fish pick your decisions.” Write your one sentence first. If it needs a setup paragraph, simplify the project.
4. Use something familiar in a way nobody expects
You don’t need new technology, you need a surprising use of the familiar. One team pointed a camera at a broom and played it like a guitar. The wow comes from the gap between “I know what that is” and “wait, it does that?” Take something everyone already uses and give it a job it was never meant for.
5. Do the opposite of the obvious
When everyone solves a problem the same way, the winning move is often to flip it. Every smart cane buzzes to warn a blind person about obstacles; Shepherd instead steers them toward the open path, like a guide dog. Look at how your problem is normally solved, then ask what the reverse would look like.
6. Scope it tiny and finish
A small thing that fully works beats an ambitious thing that half-works. Turning a confusing IKEA manual into a 3D animation you can spin around is a tight, finished idea, not a platform. Cut your plan in half, then in half again, until you’re sure you can finish and still have time to practice the demo.
7. Give the judges something to feel
Judges remember projects that make them feel something. A safety app disguised as a weather app so an abuser won’t find it, or a robot that does CPR while the ambulance is on the way, lands because there’s a real person on the other side. Make it clear who this is for and why it matters to them.
8. Spend the last hours on the demo, not the code
You win on the two-minute demo, not the codebase. Have a clean story: the problem, the one moment where your thing does the impossible-looking part, and the result. Practice it out loud. A working demo with a sharp story beats a deeper project that crashes or rambles.
The best way to internalize all of this is to see it. Browse the archive of winning hackathon projects and read what made each one win. Patterns jump out fast, and the next idea is usually hiding in there.