The most common excuse against running a hackathon is the prep effort. That's only true if you plan it like a major program. With the right decisions, five working days are enough – here's the plan we actually use.
Day 1 – Collect use cases
No ideation workshop, no whiteboard covered in 200 sticky notes. One question to everyone: which task costs you time every week and annoys you? Three sentences, via a form, deadline that evening. You'll get 30 to 80 answers, and about 15 of them will be usable.
| Criterion | Question | Disqualify if |
|---|---|---|
| Frequency | How often does this happen? | Less often than monthly |
| Clarity | Can the process be written down? | Nobody knows the current state |
| Data access | Is data available? | Access needs three approvals |
| Risk | What happens if it fails? | Direct external impact without review |
| Ownership | Who wants it? | Nobody volunteers |
Day 2 – Form the teams
Three to five people per team, always mixed: someone who actually runs the process, someone with technical affinity, and someone with decision-making authority or a direct line to it. Teams drawn from a single department build single-department solutions.
The best signal for a good team is friction in the morning. Teams that agree instantly usually end up building the obvious thing.
Day 3 – Tools and access
Set up accounts, distribute credits, prepare test data. This day decides the event's success more than any content preparation, because time lost on the actual day can't be recovered.
- Walk through every access path once with a real test user – don't just create the accounts.
- Provide synthetic or anonymized datasets; arguing about real data on the day itself burns hours.
- Define a fallback for every tool in case a service goes down.
- Check Wi-Fi capacity. Yes, really.
Day 4 – Lock the choreography
The event day runs on a fixed rhythm. No open-ended working time – instead, blocks with hard transitions. The schedule is the actual teaching instrument.
| Time | Block | Outcome |
|---|---|---|
| 9:00 | Kickoff and tool intro | Everyone has built something once |
| 10:00 | Team scoping | One sentence: what's done by tonight? |
| 10:30 | Build I | First working version |
| 13:00 | Check-in with a coach | Scope cut in half |
| 14:00 | Build II | Working core flow |
| 16:00 | Pitch prep | Three minutes, live demo |
| 17:00 | Demos and decisions | Owner and next step per project |
Day 5 – Prepare the follow-up
Sounds paradoxical, but it's the difference between a nice day and actual change. Decide in advance what happens after the event: who decides on continued development, what budget is available, when the review meeting takes place. Without those three answers, every hackathon ends in applause followed by silence.
The five most expensive mistakes
- 01Allowing use cases that are too big – the 1 pm scope cut only partially saves the day.
- 02Planning to use real data without prior approval.
- 03Inviting leadership only to the demo instead of to the kickoff.
- 04Not enough coaches in the room: one team per coach is too few, five is too many.
- 05Not having a follow-up meeting on the calendar after the event.