The doctrine.

The thesis

Roughly 1% of people build things. The other 99% use things. A hackathon is the cheapest, fastest, most reliable machine ever invented for moving a person from the second group to the first, and the research is blunt about why:

“Hackathons sometimes produce technologies, and they always produce subjects.” Lilly Irani

Only ~9% of the code in hackathon repos is written at the hackathon. Only ~7% of projects show a pulse six months later. If you judge hackathons as software factories, they're a scam. The numbers are right and I don't hide from them. Judge them as identity factories and they're the best deal in civilization: deadline + strangers + witnessed demo = a person who has publicly enacted "I am someone who builds," which is how identities actually stick.

Here is what I actually believe. A hackathon rarely produces a product. It reliably produces a reframe. It turns people into believers that they can build, including people who walked in not knowing how to code. That reframe is the point.

My goal is to take builders from 1% to 51% of people. The same way we went from a handful of internet users to the majority being online, then from a few phones to almost everyone carrying one. We get more connected every year. Using AI is the next step in that line: it is about being more and more able, and understanding a little more of the complexity in this world. That makes hackathons one of the best levers we have against inequality, and against the rampant lagging-underclass scenario Sam Altman recently put on the table. Cross the majority line and the whole shape of who gets to build changes.

So this manual optimizes for the conversion, and treats shipped projects as a designed add-on (Chapter 7, because that part is designable; well-designed programs hit 25–40% continuation vs. the 7% baseline).

That's also why hackathons belong everywhere, not just CS campuses: companies, schools, city halls, social programs, family weekends. The core is portable: a problem you care about + a team + a hard deadline + a public demo. "App" can be a service blueprint, a lesson plan, a policy memo, a rebuilt breast pump. Chapter 8.

Chapter 1: Pick your weapon

Let's be honest: there is no such thing as "a hackathon." There are at least a dozen valid ones, and they share almost no playbook. MIT Hack-Nation runs a global online venture funnel. A Lovable vibe-jam hands product credits to people who have never written a line of code. ElevenLabs runs the same three-hour event in thirty-three cities at once. NASA federates one problem set to five hundred local events. Pick the wrong archetype for your goal and no amount of good logistics saves you.

The research finding still holds: a community-building event and a prototype-producing event should look nothing alike. Choose your format from your goal, not from what MLH events look like on YouTube. The interactive picker points you at the single best fit in five questions. Here are the fifteen archetypes, each with the real event to steal from and the one move that defines its playbook:

Numbers and sources for each live in the research insight bank. One myth to kill: MLH sets no hard team-size cap; "up to 4" is a per-event convention, not a rule.

Three format truths that cut across all fifteen

• The all-nighter is dead. It was load-bearing when scaffolding took 20 hours; AI tooling ended that. ElevenLabs shipped 262 projects across 33 cities in 3 hours. Sleep deprivation is anti-flow, anti-creativity, and it's the #1 thing that screens out everyone who isn't a 20-year-old with no obligations. If you keep a 48h window, make sleep the default, not the deviation.
• Curate or gate, pick one. Cerebral Valley curates at the door (13,000 → 500; the acceptance rate is the brand). lablab.ai gates at the exit (open entry, but no working URL + video + repo = not judged). Both work. Neither-nor produces the sea of half-finished slideware you've walked past at bad events.
• Simultaneity is a cheat code. 33 cities racing one clock, or one global day with local leads (NASA's model: centralize the hard part, problem design, federate the cheap part). One event, many rooms, one story.

Chapter 2: The physics

You're not running an event. You're running an interaction ritual: synchronized attention + shared mood + a boundary against outsiders → emotional energy, group symbols, and moral commitment. That's the sociology of why a weekend feels life-changing. Your job is to aim that energy at identity formation. The levers:

Flow. Peak engagement needs three things you can literally schedule: one clear goal (the 18:00 demo), immediate feedback (mentors as a workflow, @mentor channel, roaming schedule, mid-point check-in, never hallway luck), and challenge/skill match (tracks and starter templates so beginners aren't drowning and veterans aren't bored).

Deadline ≠ pressure. Amabile's finding: intense time pressure cuts creativity dramatically unless people feel on a mission and protected from fragmentation. So: mission framing at the opening, and long uninterrupted build blocks. A deadline without meaning is just stress.

The identity moment is the demo. Standing in front of a room presenting a thing you made is a public, witnessed enactment of "I am a builder", performance accomplishment, the strongest known source of self-efficacy. This is why every team must demo, why demos are protected at all costs, and why a first-timer's wobbly 90-second demo matters more than the winner announcement.

Scarcity and status. Getting selected is an achievement people announce. Publicized acceptance rates, visible waitlists, judge lineups announced before applications close, prestige-coded venues. Parker's "generous exclusion": by closing the door, you create the room. Use white-hat drives (meaning, accomplishment) for lasting goodwill and black-hat drives (scarcity, countdown, loss aversion) for urgency, black hat gets them in the door; white hat decides whether they evangelize afterward.

Prizes are trophies, not contracts. The meta-analysis is 128 studies deep: expected performance-contingent rewards crowd out intrinsic motivation. Winning predicts two weeks of commits, then nothing. Access-prizes (dinner with the founding team, pitch time with the exec who owns the problem, early access) dodge the trap, cost you almost nothing, and are worth more than the iPad.

Who shows up is a design output. The deterrents that keep first-timers away are culture, not content: competitive climate, endurance norms, fear of insufficient experience. And theme is a demographic instrument, a hardware hackathon reframed as "Wear & Care" tripled women's participation with zero quotas. Childcare, quiet rooms, humane hours, and non-coder prize categories (NASA judges storytelling) are not niceties; they're the recruitment strategy for the 99%.

Chapter 3: The countdown

The full gantt lives in the Master Timeline with every deadline and number, in two tracks (flagship weekend at T-5 months; 3–12h compression event at T-6 weeks). The shape of it:

• T-4–6 months: goal, format, leadership team, date, venue hunt starts.
• T-3–4 months: budget, prospectus, sponsor pipeline opens, placeholder site.
• T-3 months: registration opens, marketing live.
• T-2 months: judges + mentors recruited, workshops, vendors.
• T-1 month: run of show, venue logistics done, comms cadence running.
• T-1 week: 200% registered, single paperwork deadline passed, full-team run-through.
• T-0: the middle is sacred, protect build blocks, feed people, run the ritual.
• T+1 week: surveys, sponsor report + re-up, retro, public recap, next date announced.

Chapter 4: Money

Budget. Big three cost centers on paper are venue, food, prizes, but venue is the one you should be fighting to get for free. Food $8–10/person/meal (never pizza-only, it's a signal of how much you value people), snacks $10/person, shirts $5–8. Always hold $1–3k contingency; every guide says you will need it. Hack Club ran a world-class 175-person event on $75k and published every transaction. Radical transparency is both a trust-builder and a fundraising asset.

Venue: define it early, pay for it rarely. Make the venue one of the first things you lock, because it's the long pole. But it should not necessarily be a big line on the balance sheet. Pay for a venue only when you have access to something genuinely exceptional, or when you're just starting out and don't yet have the in-kind partners and network. Ideally, after a few sessions in your city, you'll have a handful of in-kind partners: technology companies with beautiful offices, or co-working spaces, that are very happy to give you the premises for free. It's great advertising for them. They get to support active youth hackathons, they get in front of very qualified prospects (future co-workers, employees, members), and hosting one is a fantastic branding activity for most offices and co-workings. So chase the venue early, chase it in kind, and keep it small in the budget.

Catering: you will almost always pay. Food is the opposite of the venue. A pizzeria does not sponsor a hackathon easily, even if we've seen it happen. Assume catering is a real cash line every single time, budget it properly, and don't count on it being donated.

Sponsorship is sales. What sponsors actually buy (pick their lane, then package it):

1. API/product adoption + feedback, DevRel budgets. Sell: "Best Use of X" track (keep X general or creativity dies), workshop slot, dedicated channel, pre-event setup webinar, and their humans walking the floor, presence is the deliverable that predicts sponsor satisfaction, not booth size.
2. Recruiting, HR budgets, hottest in autumn. Sell: resume book, interview room, recruiter booth, short opening slot.
3. Brand, marketing budgets. Sell: the ambient surfaces (lanyards, shirts, badges), content, association with the scene.

Mechanics: 2–3 page prospectus, three tiers each anchored to ONE of the lanes above, top tier ≤25% of your budget, custom packages always available. First email plain-text with zero links or attachments (spam filters), to a DevRel/HR/Marketing title or the CEO, never a random engineer. Call → same-day customized proposal → up to 3 follow-ups → invoice the second they commit. Q1 and Q4 have the loosest budgets. Enforce prize parity: one sponsor's $50k prize kills every other sponsor's ROI. In 2026, frontier labs will often pay in credits + experts + selection prestige, take it, but don't let credits-only sponsors displace the cash that feeds people.

After the event, within 48 hours: sponsors get a metrics-and-highlights report (projects on their API, leads, gallery links) and a re-up offer for the next edition. That email is next year's budget.

Chapter 5: The room

The event starts at the invitation and ends at the second closing. Steal this sequence:

Before. Name the event as a moment, not a meeting. Application form primes builder identity (ask for something they've made). Publish judges early, people apply to be seen by specific humans. Visible waitlist. Countdown content the final week.

Threshold. A real arrival moment, named check-in, badge, music, a room that says "something happens here." Parker: a passageway that tunes out the prior reality.

Opening (15 minutes, total). Cold-open with the mission, why this weekend, why these people, why now. Then: the one goal ("working demo, live, 18:00"), the rubric (publish it now, not at judging), rules in five minutes, teams confirmed, go. Never open with wifi passwords.

The middle. Long protected build blocks. Fixed mentor windows + a help workflow. Mid-point check-in (teams discover at hour 40 they built the wrong thing, a checkpoint at half-time prevents it; teams finish ~25% of what they scope, so push brutal scoping early). Meals as the social glue, shared tables, not grab-and-go. One surprise micro-event for energy (midnight award, lightning talks anyone can give, the mascot). For >24h: quiet room, and sleep framed as strategy.

Demos. Everyone demos. Live. 2–3 minutes, hard-cut timer, no slides. Under ~200 people: full room. Over: science fair (judges circulate, 3 per project, staggered assignments) + top-N on stage. Broadcast judging progress so the room stays calm. The crowd reacting to a thing working is the best moment your event will produce, engineer for it.

Double close. Inward: winner stories (cast them, the doctor, the teacher, the first-timer), a beat of collective reflection. Outward: next date, community channel, where the projects live permanently. Never end on prize logistics.

Chapter 6: Judging (or: the courage not to)

• The math first: ~1 submitted project per 4 attendees. Judges needed = ⌈(projects × 3 judges × 4 min) / judging window⌉. 175 projects, 2 hours → 18 judges. Online: ~30 projects ≈ 5 hours per judge; give a 1–2 week window.
• Stack ranking beats scorecards. Each judge returns only a top 3 (3/2/1 points). Normalizes harsh vs. generous judges, runs in a spreadsheet, and you personally validate + cheating-check the bubbled-up top 5 before announcing.
• Publish the rubric before hacking starts and run a 15-minute judge calibration. Solid spine: working demo, technical execution, originality, impact. Differentiators worth stealing: shippability ("could we use this next week?", Atlassian), simplicity (HackerEarth), documentation & approachability (GitHub).
• Never eliminate teams before submissions. MLH refuses to sanction it; so should you. Brief judges to reward learning over startup-ness, 99% of hackers aren't fundraising.
• Or don't judge at all. GitHub's completion model (everyone who ships gets the reward), Hack Club's peer emoji-voting, Microsoft's company-wide video votes. If your goal is conversion or community, judging is optional logistics you can delete. Many small named awards beat one winner, multiply the number of winning identities.

Chapter 7: The afterlife (where 93% of events fail)

The evidence: winning predicts two weeks. What predicts months is skill fit, skill diversity, small teams, and explicit intention. All designable:

1. Before demos, every team writes a next-30-days plan. Two lines. Intention formed at peak motivation is the single cheapest survival intervention.
2. Announce the container during the event: the follow-up demo day, the monthly hack night, the incubation slot, the manager-sanctioned Friday. Projects and identities both decay without a home.
3. Steal Facebook's Prototype Forum: demos to people with power happen 1–2 weeks after the build, polished pitches to an audience that can green-light, not 3am slideware. For companies this is the difference between demo theater and shipped outcomes; pair it with Atlassian's trick of judging on shippability.
4. Budget the aftermath before the catering. AngelHack: post-event resources are "almost always the highest-impact budget line." Pre-commit funding to put the top 2–3 projects through a validation sprint.
5. Permanent public artifacts: project gallery pages, winner-story posts, pinned repos. The event compounds only if the work stays visible. Hand winners the megaphone, their recap posts are your marketing.
6. Measure like a funnel, on an honest clock: participants → submissions → flagged → funded → shipped, reported at +2 weeks, +3, +6, +12 months. Internal programs: full ROI cycle is 12–18 months; say so up front. The exec pitch numbers: McKinsey claims 25–50% time-to-market cuts; ShipIt produced Jira Service Management; Hack Week produced Discover Weekly; a hackathon produced the Like button.

Chapter 8: Beyond tech (the 51% mission)

The portable core is problem + team + deadline + witnessed demo. Everything else is skin. To transplant the format:

• Schools: demo = anything makeable (a lesson, a zine, a robot, a campaign). Research on youth hackathons shows creativity and self-efficacy gains, when the competitive-endurance culture is stripped out. Teachers as roaming mentors, parents as the demo audience.
• Companies: run it as a pipeline instrument wearing a party costume. Shipment orders before, sacred middle, Prototype Forum after, funded follow-through. Everyone hacks, including the chefs (Shopify), "not your day job" and "first-timers must hack" (Facebook) are the two rules that keep it alive.
• Civic and social programs: weeks of expert problem-definition first, a real problem-owner per team, and wire the sprint into slow institutions (the Breast Pump hackathon ran a policy summit alongside the build), otherwise it's theater. Recruit with "you don't need to code."
• Family retreats: the smallest viable hackathon is one household, one Saturday, one problem someone actually has, demos at dinner. The threshold ritual and the witnessed demo do the same identity work at N=6 as at N=600.
• The ethical line (from the format's sharpest critics): keep the ritual, fix the distribution. Participants own their IP, their portfolio, their story. If a sponsor extracts free R&D, name it or don't do it. The person being built is the primary beneficiary. That's the whole point of the 1%→51% project.

Appendix: the cheat numbers

Open the Master Timeline → Download as markdown ↓