Why Great Companies Are Built in Hackathons (and How to Run Them Right)

Source: Product for Engineers (PostHog) · Author: Ian Vanagas · Date: April 21, 2026 · Original article

---

Most companies treat hackathons as a fun-but-fluffy distraction — a couple of days where engineers stay up late, eat pizza, and produce nothing the business actually uses. PostHog argues this is a misread. Their hackathons have generated millions in revenue and birthed several of their core products: Session Replay, Data Warehouse, Logs, Workflows, and PostHog AI would not exist without them. The reason most hackathons feel like theatre isn't that hackathons are bad — it's that companies run them wrong. This post lays out the five rules PostHog follows.

1. Hackathons are an innovation engine — but only when fully separate from work

The single most common failure mode: hackathons that quietly become "a chance to push the roadmap forward faster." Once that happens, the whole point is dead. People work on the same things they always work on, just with worse sleep.

PostHog enforces two simple rules to keep the firewall between hackathon and day job:

1. You must work on totally new things. Pitching anything from the existing roadmap is forbidden. Hackathons are reserved for ambitious, weird, half-baked ideas and for trying technologies you've never touched before.
2. You must focus 100% on the hackathon. They run hackathons during company offsites, with explicit coverage plans for support and incidents so participants are genuinely off the hook from regular work. (DigitalOcean does the same thing differently — they declare a formal "work embargo" for hackathon days in the office.)

Why this matters in practice: when an engineer is half-watching Slack for incidents or trying to ship the feature their PM is waiting on, they will pick a safe, incremental project. Take the safety net of "I can fall back to my day work" away, and people swing for the fences.

The author's favorite example is Session Replay. In PostHog's earliest days, an engineer wanted to build it during a hackathon based on user feedback. Co-CEO James actively argued against it, saying it would take too long and split the company's focus. The engineer built it anyway. It hit 50,000 daily active users and turned PostHog from a single product into the multi-product company it is today. The author cites an early Facebook engineer's line — "code wins arguments" — as the principle at play. Without a hackathon, that argument never gets settled, because the code never gets written.

Takeaway: Give people explicit permission and cover to ignore their day-to-day. Skip this and you get low participation, burnout, and timid projects.

2. Hackathons are for everyone, not just engineers

The mental image of a hackathon is engineers hunched over laptops. PostHog's hackathons mostly look like that — with one big difference: the non-engineers are in the room and shipping things too.

The reasoning is that LLMs (and tools like Claude Code) have collapsed the cost of "being able to build software." Combine that with deep domain expertise from sales, support, design, ops, or legal, and you get projects an engineering team alone would never come up with. PostHog's non-technical team members have shipped hackathon projects like:

• Games for DeskHog (PostHog's open-source developer toy) — Three Button Dungeon, Awkwardness Avoider, Flappy Hog.
• Instagram Stories for PostHog showcasing new features in a format people already understand.
• A DPA generator that turns a tedious legal document into something pleasant.

Non-technical participants typically need more encouragement to pitch and more support to actually build, but the cultural payoff is huge. It breaks down silos. DigitalOcean's own observation matches: their most innovative hackathon outputs come from cross-functional teams. Twilio explicitly discourages "lone wolf" projects to force this collaboration; PostHog does too.

There's a second-order effect: when a non-engineer ships something with an LLM during a hackathon, they often start using those tools in their day job. That's why companies like Jane, Uber, and Vanta are deliberately using hackathons as their primary AI-adoption mechanism. Slack, after five years of running hackathons, summarized it bluntly: "the more people participate, the better your outcomes."

Takeaway: Invite (and equip) people who would never picture themselves at a hackathon. Form cross-functional teams on purpose.

3. Demos aren't optional

Every team must demo. This single rule does more work than it looks like.

The author tells the story of "RealTimeHog 3000" from the 2024 Mykonos hackathon — a livestream service that showed events the moment they hit PostHog's ingestion Kafka topic, using server-sent events. Cool. But then came the "one more thing" moment: a globe on posthog.com showing every event being captured worldwide across PostHog's US and EU clouds in real time. That's the kind of thing that only comes out when you know you have to show something.

Mandatory demos work as a forcing function: wildly ambitious plans naturally get pruned down to "something we can actually show in 48 hours" — which usually means something real. Demos are also where the magic happens socially. When someone says "this is live now" or "users are already on it," the room reacts. People love a bit of showmanship, and being in the spotlight is part of the reward.

A subtler point: while PostHog makes demos mandatory, they consider judging and prizes optional — and probably counterproductive. Their argument is that they hire people who are intrinsically motivated ("be the driver" is a stated company value); a $50 gift card is insulting to that motivation. Worse, prizes warp behavior: people start building what they think will win, or what the bosses want to see, instead of what they actually believe in. Take the prize away, give people autonomy and time, and the projects get more interesting, not less.

Takeaway: Tell everyone up front they will demo, and make sure everyone does. Bonus: keep a written record of what people demoed — these ideas evaporate fast, and the writeups make excellent blog content.

4. The best hackathon projects ship

The biggest knock on hackathons is that the work evaporates the moment the offsite ends. PostHog's counter is that this is a process problem, not an inherent flaw.

The clearest illustration is how their Logs product happened:

1. Day of the 2025 offsite hackathon: the team built OTEL log capture into ClickHouse, a query API, and a basic frontend.
2. After the offsite: Frank, who happened to be looking into an internal logging solution anyway, decided to keep going. He thought he could get it to "good enough" within one sprint.
3. Two weeks later: he was right. It had filtering, search, and was fast — usable internally.
4. Then it sat on the back burner, but Tim kept mentioning it as something they wanted to build, and customers kept asking.
5. Four months later: Frank picked it up again. Because the internal version already shipped, restarting was much cheaper. In Q4 planning, Logs was promoted to a real priority, given its own team, and pushed toward a proper launch.

PostHog admits they don't have a polished "hackathon-to-production pipeline." Instead they rely on the product engineer model: a single person willing to "be the driver," push the project forward, and being given the freedom to do so. The crucial unlock is giving that person some slack after the hackathon — a little room to wrap up, ship internally, and document. Without that buffer, the project dies on Monday.

A practical force-multiplier: real customer demand. For Logs, PostHog priced what Datadog would have charged them — a minimum of $260,000/month — and that number alone made finishing the project a no-brainer. Internal customers count.

Not every project ships, and the author is explicit about this: dead-end projects are part of the messy reality of innovation. But the possibility that a hackathon project ships changes how seriously people take it.

Takeaway: Encourage the "driver" mentality and give people post-hackathon slack to take projects further.

5. Make hackathons a tradition

At PostHog's 2025 Mexico hackathon, 10 of the 17 projects had been pre-discussed in their #hackathon-ideas Slack channel, sometimes months in advance.

That number is the whole point of this section. When people know there will be another hackathon, they start saving up ideas year-round — and weird ideas that would never survive a roadmap meeting accumulate in one place. Many of these ideas don't even need a hackathon to ship; they end up inspiring features that teams build during normal sprints. A roadmap, by its nature, filters out the strange and ambitious; a hackathon-ideas channel preserves them.

This isn't a new trick. Early Facebook hackathons had an internal wiki for sharing ideas, and several of their most-loved products — Video, the Like button, Chat, HipHop for PHP, Timeline — started there.

The other benefits of treating hackathons as a tradition:

• People are less restless in their day jobs because they know they'll have a sanctioned outlet for "the thing I really want to build."
• The hackathon becomes a perk and a cultural cornerstone. It signals that the company genuinely values autonomy and is willing to spend real time on it.
• It generates lore: the time PostHog's AI chatbot insisted the company mascot was named "Hoge" lives on as a story that bonds the team.

Tradition turns the hackathon into a kind of promise from the company: we will keep making space for the weird and wonderful things you believe in, not just the items on the roadmap. That promise, the author argues, is what turns hackathons from a perk into a foundation for building a great company.

Takeaway: Start calling it your "annual hackathon" before it is one — manifest it. Spin up a #hackathon-ideas Slack channel today and dump every "we should build this" thought into it.

---

The TL;DR rulebook

1. Separate it from work. No roadmap items, full focus, real coverage plans.
2. Open it to everyone. LLMs make non-engineers builders too; cross-functional teams produce the best stuff.
3. Mandatory demos, optional prizes. Demos force shippable scope. Prizes distort motivation.
4. Plan for shipping. Empower a "driver," give them slack after the event, and watch for real customer demand (internal counts).
5. Make it a tradition. A persistent ideas channel + an annual cadence compounds over years.

Run hackathons this way and they stop being a distraction from "real work." They become the place where some of your most important real work actually starts.