Hackathons are a type of drug - once an addict, always an addict. I’m co-organizing an after-hours one here in Warsaw (May 6 2026 – Luma 👋), and deeply believe every tech org deserves a good hackathon too.
This is my internal hackathon playbook for every startup/scaleup - principles out of having done 15 of these over the last few years:
1. Fuck productivity
Rule number one - talented, cracked people have insane amounts of creativity lying dormant under everyday work most of the time. The whole value of a hackathon is in the wildcard energy, divorced from actual work. Hackathon ideas must not be work that’s planned anyway. The point is to get out of the Matrix.
At PostHog, we do an all-company hackathon once a year, but team meetups throughout the year are awesome for doing mini hacks more often. Team-level hackathons can be scoped a little more than company-wide ones, but still can’t be your next sprint’s plan.
Like startups, most hackathon projects don’t live long, but some DO change everything, and even doomed ones result in learnings.
2. Lock in
This HAS to be in-person. Lots of knowledge work can be done remotely with great results, but it’s deranged IMO to run a hackathon remotely and mid to run one in your everyday office. “Have some pizza, now just work overtime.”
Let’s start with the premise: we’re talking about absurd focus on one project for a brief amount of time. You can try to do this in your regular environment - it’s just not going to be that focus. Get somewhere away, unusual, further from distractions. It can be as simple as a venue in town, or as fancy as a tropical island. Scenery begets camaraderie.
In terms of scheduling, 24 hours works well as a rule. Teams form one afternoon, demo the next afternoon. (Please do get sleep.) 36 hours is great for high ambitions. Teams form one evening, build the whole next day, and demo the afternoon of day after that.
New: thanks to vibecoding agentic engineering, a 3-hour-ish timeline has become surprisingly workable too… with just some slop in the results.
3. Run a market of ideas
How to turn that wildcard energy into actual teams? Simply create a regulated market running on post-its, in just 5 easy steps:
A. Everyone writes up 1-3 post-its, each with one idea - for visibility, use bold markers, not pens.
B. People pitch their proposals in 30s or less, putting their post-its on a wall.
C. Now, the politics – have participants tear a post-it in half and write their name on both halves. Each person votes by putting their name on exactly two projects they want to join most (and only one can be their own project). Savvy hackers convince others here. Pro ones have already done planted seeds way before. This situation is always dynamic though.
D. Finally, in the second round, only projects with actual interest remain (i.e. at least 2 votes). Everyone must now choose only one project. The moderator is here to ensure no projects are just one person, and no teams are larger than four.
E. Profit! Time to build. How and where - that’s up to the teams, what matters is that everyone is in their optimal team.
4. Ensure energy
I don’t mean vibes, I mean literal electricity. A lack of outlets can break the whole thing, and I’ve seen this happen! You can make do with a crowded space, you can’t make do with dead laptops.
There’s a few of these practical requirements:
- Power - make sure to have some extenders at hand, as either way outlets are often too far from seating; laptop-sized powerbanks can save the day, but not for long
- WiFi speed - there’ll be heavy-ass Docker images downloaded all around; the connection must support everyone doing this without slowing down to a crawl (I’ve heard of Starlink as an option for remote locations, but haven’t actually tried)
- Ventilation - airtight conference rooms become unbearable after a couple of hours with smells and temperature, not to mention CO2 levels; make sure there’s fresh air flowing in
- A stage to demo on - demos can technically be done on a shared video call, but the energy of an in-person demo is unbeatable; really all you need here is a large screen and the space to gather around it
- A whiteboard - when you need one for a project, you need one bad; usually just one or two to share is enough for everyone
If running the event in a new venue, scout it out beforehand for the above.
5. Optimize for fun
Ultimately, all of this effort already is disconnected from your sales pipeline. The rule is that builders gotta demo with live features, bad jokes, and no slides. Unhinged energy is what projects are remembered for here, definitely not business impact.
Keep things on track too when demoing - there must be a dictator in charge, not necessarily benevolent. 3 minutes is usually a good limit per demo. Put up a countdown that only the presenters can see, so that people naturally adjust their timing to the limit.
Questions? Maybe, maybe not - I lean towards none. There’s always that damn person with “ummm, so, more of a note than a question…”
6. Ship it
You’ve already built it. Often, you should ship it.
A lot of the work will be throwaway, but some projects you can deploy to production. Even if raw in that initial iteration, often the only way to learn what works is to give actual users something.
The key bit here is to plan for some shipping. Everyone should know that the team’s schedule might be thrown off for a few days after hacking. Maybe a bit longer. I’ve seen hackathon projects turn into minor production features, and I’ve seen others spin off into full-on teams. And sometimes, you have to tell yourself – or someone else on the team – that was fun, but that is it.
Details vary, but a shipping mindset can simply 10x the potential upside of the whole affair.
The real product of a hackathon project?
The demo and the friends we made along the way. The trash code maybe, maybe not.
Lmk in comments if you’ve got anything more on hackathons that I’ve missed.
And just before you go - this is important - check with Marius if you’re even capable of using post-it notes correctly: