Courses reward correctness. Hackathons reward something that runs. Both matter, but the second teaches you things lectures can't.
I've built under hackathon-style deadlines on three projects: GigShield (a team of three, March to June 2026), Knot.ai (the Echo Sphere × Agora hackathon, August to September 2026) and Hospitality.ai (the GE HealthCare Precision Care Challenge 2026). This post is about what that format forces on you, what it can't teach, and a set of habits for getting the most out of one.
What the deadline forces
Cutting scope without agonising
When time is fixed, scope is the only thing that can move. A hackathon makes you practise deciding what not to build, quickly, without the luxury of perfect information. In normal projects that decision gets postponed forever.
A useful question: what is the smallest thing that still demonstrates the idea?
Choosing familiar tools
It's not the time to learn a new framework. The fastest way to lose a weekend is to debug a tool you don't know while also building a product. Use what you already understand, and spend your novelty budget on exactly one thing that matters to the idea.
Demo-first thinking
If the story isn't clear in two minutes, the features don't matter. Judges and users meet your project through a short demo, not through your code quality. That forces you to think about the experience of understanding it, which is a skill product people use all the time.
Splitting the problem so the hard part is isolated
Knot.ai is a good example. The hard part wasn't the UI. It was keeping an AI interviewer under control. Isolating that, with a server-side state machine for difficulty and topic coverage while the model handled judgement and phrasing, meant the risky piece could be built and tested on its own.
What a hackathon exposes
A tight deadline makes your shortcuts visible, and after each sprint it's worth listing what you'd have done with more time. Reading the "limits" sections of those projects gives a decent picture of what a sprint leaves behind:
- Knot.ai's voice path is the thinner-tested surface, and its state is single-node.
- Hospitality.ai runs on synthetic data and doesn't read scanned PDFs.
- GigShield's payouts are simulated, and some state lives in browser storage.
None of that is a failure. It's the honest shape of work done against a clock. The mistake would be pretending otherwise.
What a hackathon doesn't teach
- Maintainable code. A weekend prototype optimises for speed of writing, not ease of changing.
- Tests. Under time pressure they're the first thing dropped.
- Sustainable pace. Sprinting teaches you to sprint, not how to keep going for a year.
- Real users. A demo audience is not a customer. Their questions are different.
A habit worth keeping
After building something fast, schedule a clean-up week, or admit to yourself it's a prototype. Lying to yourself about quality is how prototypes quietly become production.
A practical playbook
Before
- Agree the one-sentence idea.
- Pick the stack you already know.
- Decide the roles (see Day 8) and the contract between pieces.
- Check the rules: what's judged, what's allowed, what must be live.
During
- Get a thin end-to-end path working in the first few hours, however ugly.
- Write the demo script before the last feature. It tells you what to cut.
- Deploy early. Don't discover hosting problems at the deadline.
- Keep a "not now" list (Day 10).
- Sleep. A rested person debugs faster than a heroic one.
After
- Write down what's real and what's faked, while you remember.
- Fix the one thing that embarrassed you in the demo.
- Turn the work into a case study, including limits.
A tip on honesty in demos
If part of your demo is mocked, simulated or stubbed, say so. It's tempting to let a mock look real. But being clear about it earns more respect than being caught, and it makes your real parts more credible.
A 24-hour timeline template
Most hackathon time disappears at the beginning and the end. A rough plan helps. Scale it to your event's length.
| Hours | Focus | Output |
|---|---|---|
| 0–1 | Agree the idea; read the rules and judging criteria | One-sentence pitch |
| 1–3 | Roles, contracts, repo, deploy skeleton | A live "hello" on the real URL |
| 3–10 | The one core feature, end to end | A thin path that works, however ugly |
| 10–16 | Second feature, error handling, data | Something worth demoing |
| 16–20 | Cut scope, fix the embarrassing bugs | A stable build |
| 20–22 | Demo script, screenshots, README | A story in two minutes |
| 22–24 | Rehearse, deploy, sleep if you can | A calm demo |
The deploy skeleton in hour 1 to 3 is the part people skip, and it's the one that saves the final hour.
Design for the judging criteria
Read the criteria before the first line of code. Typical ones, and what they imply:
| Criterion | What judges look for | How to show it |
|---|---|---|
| Innovation | Something fresh, not a clone | One distinctive idea, stated early |
| Technical depth | Hard parts handled well | Name the hard problem and show your solution |
| Usability | A stranger can use it | A demo with no explanation needed |
| Impact | A real problem and a real user | A named persona and a concrete scenario |
| Completeness | It works end to end | A thin full path beats three broken features |
Where the rules mention a sponsor's technology, plan how to use it meaningfully, since a token integration is easy to spot.
A demo script template
Two minutes is shorter than you think.
- Hook (15 s): the problem in one sentence, with a person in it.
- Show (60 s): the one flow that matters, live or recorded.
- Why it's hard (20 s): the interesting technical decision.
- What's next (15 s): what you'd build with more time.
- Ask (10 s): invite questions.
Rehearse out loud at least twice. And record a backup video: Wi-Fi fails at exactly the wrong moment.
Team dynamics under pressure
- Decide who has the final say on scope when you disagree.
- Check in every few hours for five minutes: what's done, what's blocked.
- Protect each other's sleep. Tired people write bugs.
- Share credit in the demo, by name.
- Keep the mood light. Humour is a performance tool.
After the event
The weekend isn't over when the demo ends. In the following week:
- Write down what's real and what's faked while you still remember.
- Fix the one thing that bit you on stage.
- Write a short case study including limits.
- Thank the organisers and your teammates.
- Decide, honestly: is this a prototype to retire, or a project to continue?
Common mistakes
- Starting a new framework during the event.
- Building features the demo never shows.
- No deploy until the last hour.
- A demo that depends on a fragile live connection.
- Treating a mocked feature as real without saying so.
Did a hackathon change how you code? What did you drop first when time ran short?
☕ Enjoyed this post? You can support my writing on Ko-fi.
