How to run an AI hackathon that actually ships something
Most hackathons end the same way: a room full of tired people, a slide deck, a winner, and nothing anyone opens again on Monday. The format is not broken. The incentives are. Here is how I design the weekend so something survives it.
1. Narrow the brief until it hurts
"Build something with AI" produces forty variations of the same chatbot. A brief that names a user, a constraint and a moment produces work you can compare. I write the brief with whoever owns the outcome — a technopark, a university, a sponsor — and I cut it until a team could realistically finish inside the build window.
The test: if two teams pick the same problem and still build different things, the brief is right. If everyone builds the same thing, it was a prompt, not a brief.
2. Pre-approve the tooling
Tool selection is where hours disappear. I give participants a short, opinionated stack and get them access before doors open — Lovable for shipping the product, n8n for automation, ElevenLabs for voice, plus whatever the sponsor genuinely wants tested. Not a sponsor logo wall: a stack people actually use during the weekend.
Onboarding happens in the first session, together, out loud. Nobody should be reading docs at 2am to figure out where their API key went.
3. Force contact with reality on day one
The single highest-leverage rule I use: every team talks to someone outside the room before they write code. Five conversations, same day. It kills the projects that only exist because they sound clever, and it gives the rest something to point at during judging.
This is also why mixed teams beat all-engineer teams now. Building got cheap. Understanding did not.
4. Judge the decisions, not the demo
When everyone has the same tools, polish stops being signal. I score four things: clarity of the problem, evidence of user contact, what the team deliberately cut, and whether it runs live in front of judges. Slides are optional. Working software is not.
I brief judges in advance with the same rubric the teams see. Fair judging is mostly about removing surprises.
5. Design the two weeks after the weekend
This is the part institutions skip and then wonder why nothing compounds. Before the event, I decide what happens next: which teams get follow-up sessions, who reviews their progress, what the deadline is, and what they are being pushed toward — usually a first real user, not a pitch.
A hackathon with a follow-through window is a program. Without one, it is an event. Both are fine — but only one changes numbers.
When a hackathon is the wrong answer
If your goal is a visible activation, a hackathon is efficient. If your goal is founders who keep building, run a multi-week program and use the weekend as its opening. I do both, and I say which one fits before quoting either.
Questions I get asked every time
How long should an AI hackathon be?
Two days of build time is enough when the brief is narrow and the tooling is pre-approved. Anything longer usually pads the schedule instead of the product. If you want real traction, add a two-week follow-through window after the event rather than a third build day.
Do participants need to code?
No. With AI-first tooling, mixed teams outperform all-engineer teams because someone is talking to users while someone else is shipping. I ask for one person per team who can hold a customer conversation.
How do you judge AI projects fairly when everyone uses the same tools?
Judge the decision, not the demo. I score problem clarity, evidence of talking to real users, what the team cut, and whether the thing works live in front of the judges. Polish is cheap now; judgment is not.
What does it cost to run one?
It depends on venue, headcount and how much of the delivery you keep in-house. The bigger cost is usually the one nobody budgets: someone senior owning the two weeks after the event.
Is a hackathon the right format at all?
Not always. If your goal is a pipeline of teams that keep building, a multi-week program beats a weekend. Hackathons are best for activating a community, testing a cohort, or giving an institution a visible starting point.
Working together
I design and run these end to end.
Programs for institutions, private rooms for teams. Your brand, my reputation on the line.