I have done enough hackathons at this point to have a system, but NexHacks at Carnegie Mellon is the one that actually forced me to follow it under real pressure. Twenty-four hours, a team that had never worked together before Friday night, and a judging panel that cared more about a working demo than an ambitious pitch deck.
The scoping mistake everyone makes
Almost every team walks in with an idea that is too big for the time box. We did too, for about the first two hours. The instinct is to keep the ambitious version and just "move fast." What actually works is the opposite: cut the idea down until the smallest version of it is still worth showing, then build only that. We ended up cutting two planned features from our original pitch in the first three hours. Neither cut mattered by the time we demoed — nobody in the room knew what we did not build.
Build the demo path first, not the architecture
This is the one that took me the longest to internalize. In a real project, you build foundations first because you are optimizing for months of future work. In a 24-hour hackathon, you are optimizing for one specific five-minute walkthrough. So we wrote the demo script before we wrote most of the code: what does the judge see, in what order, and what has to work flawlessly in that exact sequence. Everything not on that path got the minimum viable implementation, or got cut outright. Our AI agent's error handling for edge cases outside the demo flow was, honestly, nonexistent — and that was the correct call for the time we had.
What separated the top placements
Watching the other finalists present, the pattern was consistent: the projects that placed had a demo that ran live, start to finish, with no "imagine if this worked" hand-waving. The projects that did not place usually had a more ambitious idea but were showing screenshots or a partially working flow with a lot of narration filling the gaps. Judges can tell the difference immediately, and it changes how much they trust every other claim you make about the project.
The other consistent trait: teams that could answer "what would you build next" with something specific and technically grounded, not just "more features." It signals the team actually understood the problem space instead of building toward a demo and stopping there.
What I am taking into the next one
Scope ruthlessly, script the demo before the code, and treat the last two hours as a dead zone for new features — that time is for making sure the thing that works, works every single time you run it. Nothing kills a strong project faster than a live demo failing in front of the judges because of a change made twenty minutes before presentations.
Winning Seda AI Researchathon shortly after reinforced the same lesson from a different angle — that one was research-focused rather than demo-focused, and the projects that stood out were the ones with a genuinely narrow, well-defended claim instead of a broad one. Different format, same underlying discipline: know exactly what you are trying to prove, and prove only that.