Use one page
AngelHack recommends a single-page demo script with problem, before state, trigger, aha moment, and close. That is enough structure for a hackathon. More pages usually mean the team has not chosen the main path.
Template: one sentence problem, before state, demo trigger, aha moment, technical proof, tradeoff, next step. If the script cannot fit on one page, cut features before cutting clarity.
Use the 30 percent problem rule
AngelHack says the winning split is closer to 30 percent problem and 70 percent solution, not 5 percent problem and 95 percent solution. Too little problem makes the build feel arbitrary. Too much problem turns the pitch into a lecture.
Write the first paragraph like this: who has the pain, what breaks today, why now. Then move into the demo. The judge should understand the stakes before the first screen, but not wait two minutes for the first screen.
Open with a real user
Jackie Luc's House Guard pitch used a cabin owner discovering flood and broken-window damage too late. That made the problem concrete before the team showed sensors, dashboard, and SMS alerts.
Chris Ho's Training Rails pitch used a train derailment that happened less than 24 hours before judging as the hook for rail defect detection. The hook worked because it made the risk legible without inventing drama.
Script the demo trigger
TechCrunch says the demo should show resolution to the initial problem so the audience sees what the project does and that the key components are complete. The trigger is the moment your user takes the action that proves the app.
Write the exact sentence that moves from story to screen: now the cabin sensor fires, now the rail image comes in, now the tutor ingests the notes. Without that handoff, the demo feels like a product tour instead of a proof path.
Name the technical proof
Maria Yarotska from NEAR told Devpost she looks for problem understanding and startup mindset, not only technology. The pitch still needs technical proof, but it should be tied to why this implementation solves the user problem.
Say what was hard in one sentence: multi-frame vision, hardware signal, retrieval quality, platform integration, or real-time latency. Then show the artifact. A judge cannot score invisible difficulty.
Prepare for Q&A before it happens
Jackie Luc reported that one judge said the House Guard team was so thorough there were no more questions to ask. That is not luck. It comes from explaining target audience, core path, and tradeoffs before the judge has to dig.
Close with the next credible step, not a fantasy roadmap. Richard Moot told Devpost he loves connecting with standout teams after a competition. Give that judge a specific reason to keep the conversation going.
< read by a human · updated as things change >
browse hackathons