The output is in the repo
There's a particular feeling at 2am on the second day, when a team that met on Friday finally gets the thing to compile. You can't manufacture that with a stage and a sponsor banner. You can design for it.
Everything we build is meant to produce evidence, and hackathons make it easy, because they end in artefacts. Working prototypes. Submitted projects. Teams that formed. Developers who signed up for your platform and were still building on it ninety days later. Nobody has to argue about whether something happened.
Justin Ng, our co-founder, spent five years at AngelHack — the world's largest hackathon organisation, with a global developer community over 500,000 strong — before starting Mochi. We know what separates a hackathon that produces a press release from one that produces a pipeline.
Three things we do differently
- Recruit for the outcome, not the room. Two hundred warm bodies is a photo. Forty developers who match your ICP is a pipeline. We recruit against who you actually want building on your platform.
- Judge on what you want to happen next. The judging criteria are the strategy — they tell every team what to optimise for. Most hackathons pick them the week before.
- Measure at ninety days, not on the night. Sign-ups on the day tell you about your marketing. Retention at ninety days tells you about your platform.
Who this is for
Platform and developer-relations teams, corporate innovation and R&D groups, and companies who need to be credible with a technical audience rather than merely visible to it. The buyer here is usually different from the brand-marketing buyer, and so is the room.
When to bring us in
Early enough that the judging criteria can still be designed rather than picked. Recruitment against an ICP takes lead time, and the ninety-day measurement window only exists if the instrumentation is agreed before the event, not bolted on after it. Eight to twelve weeks out is comfortable.
Reading on how we think about this
- Impact Measurement — the operating system underneath every practice, including this one.
- The Anatomy of a Memorable Moment — why the 2am moment is designed, not lucky.
- 6 Questions That Should Live At The Top Of Every Brief — the brief-stage filter we apply before agreeing to run anything.
- Impact Measurement for Events — the three signal categories and three timing windows we measure against.
Common questions
How do you measure whether a hackathon worked?
Sign-ups on the day tell you about your marketing, so we measure at ninety days instead: how many developers are still building on your platform, how many teams stayed together, and what actually shipped. Hackathons make this unusually clean because they end in artefacts — the output is in the repo, so nobody has to argue about whether something happened.
How many developers should a hackathon aim for?
Fewer than you would expect, matched more tightly than is comfortable. Two hundred warm bodies is a photo; forty developers who match your ideal customer profile is a pipeline. We recruit against the outcome you want rather than against the size of the room.
Who runs hackathons at Mochi Collective?
Justin Ng, our co-founder, spent five years at AngelHack — the world's largest hackathon organisation, with a global developer community over 500,000 strong — running programs there before starting Mochi. You get founders on the work rather than a pitch team.