Hackathons are a type of drug - once an addict, always an addict. I’m co-organizing an after-hours hackathon here in Warsaw next week (Wednesday, May 6 2026 👋), and deeply believe every tech org deserves good ones too. This is my internal hackathon playbook for every startup/scaleup:
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 work very well. 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. Then, each person puts 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 recruited a team beforehand. The situation always is dynamic though.
D. Finally, in the second round, only projects with some interest remain. Everyone must now choose only one project. The moderator is here to ensure no teams of one, and no behemoth teams above four members.
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. Logistics 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.
If running this event in a new venue, scout it out beforehand for outlets, but also any other amenities. 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.
5. Optimize for fun
Ultimately, all of this effort already is disconnected from your sales pipeline. The rule is that builders gotta tell stories with live features and bad jokes. No slideshows. 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. 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 – stop.
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: