Before hour 0: remove known blockers
AngelHack says to treat a hackathon as prep, build, and follow-up, not just a 48-hour sprint. Prep is where you install tools, read rules, collect boilerplate, and decide what you will not build.
Chris Ho reports that Twilio A2P 10DLC could take 2 to 3 days and that Instacart API approval forced a switch to DoorDash in another hackathon. If an API needs approval, sign up before kickoff or choose a different proof path.
Hours 0 to 2: rubric, team, sentence
Devpost says teams should review requirements before building, including eligibility, required tools, URLs, and demo limits. The first two hours should turn those requirements into a scoring checklist.
Jackie Luc's CalgaryHacks team clarified the theme with organizers and defined roles after a prior overambitious failure. By hour 2, write one user sentence, assign owners, and delete any feature that does not appear in the pitch.
Hours 2 to 12: skeleton first
AngelHack recommends a working skeleton by hour 12 in a 48-hour event. Skeleton means the demo route exists end to end, even if data is fake, UI is ugly, and the model answer is cached.
House Guard won because the team focused core functionality: sensor signal, dashboard, alert. The same rule works for AI, web3, and hardware. One ugly path beats five half-started modules.
Hours 12 to 32: prove the hard part
Training Rails spent the build making rail defect detection visible through hardware, YOLO, Supabase, FastAPI, and a physical demo prop. That is the middle block: make the hardest claim testable, not perfect.
Medusa Paystack plugin split measurable tasks around platform user flows and Stripe-parity behavior. If your team has three builders, run parallel work only where interfaces are clear. Otherwise you create merge pain instead of progress.
Hours 32 to 44: freeze scope and draft submission
Devpost recommends starting a draft submission early because it can be edited before the deadline. Use this block to write the project description, add screenshots, record the rough demo, and verify repo visibility.
Devpost winner Betsy says there is usually a last-day frenzy even with time-management intentions. The point of hour 32 is to stop pretending the frenzy will be rational. Freeze the feature list and fix only what blocks the demo path.
Hours 44 to 48: lock, rehearse, submit
AngelHack recommends locking code four hours before submission. Use the final block for demo recording, screenshots, README cleanup, deployment checks, and submission QA. New features after hour 44 are usually just new failure modes.
MLH says final presentations need about 7 minutes per team when finalists demo at closing, with 3 to 5 minutes for presentation and 2 minutes for setup. It also says judging usually takes 2 to 3 hours. Your final output has to survive that schedule without you explaining every missing detail.
< read by a human · updated as things change >
browse hackathons