Winning Hackathons, and Coaching the Teams That Do: Build Less, Prove More

Every hackathon ends the same way. Dozens of exhausted teams, each convinced that what they built is the most impressive thing in the room, get a few minutes in front of people who have already seen twenty other projects that day. Many of those teams lose in the first thirty seconds, and not because their code is worse. They lose because the judge cannot yet tell who the product is for, whether it works, or why it matters.

I have been on both sides of that table. I have finished on the podium at four hackathons, including first places in 2024 and 2025, and since late 2023 I have mentored and run hackathons as an instructor at CIIT and Eskwelabs. Seen from both sides, the lesson is the same: the teams that win are rarely the ones that built the most. A short, hyperfocused solution beats an extensive platform that ends up as one of many — and the advice I give the teams I mentor is the advice I follow myself.

My argument is this: hackathons are not won by the team that builds the most, but by the team that makes a judge’s three minutes easiest to score — and the same discipline that wins the room is what keeps a project alive afterwards. That discipline has four parts, which I call the differentiation stack: a sharp user, real data, a demo that works on the one path that matters, and a credible next step. None of them requires heroic engineering. All of them require deciding, early, what not to build.

The article starts with the numbers — how long the odds are and how short the window is — then sets out a framework built from the published judging criteria of major organisers. Five deep dives follow: where teams land, what reliably loses, how to pitch, how to build and coach a team, and what happens after the prizes. It closes with case examples, objections, implications, a 36-hour playbook built on my own practice, and the limits of the evidence.

Context: why this matters now

Hackathons are no longer a niche weekend hobby. Major League Hacking, the largest student hackathon league, reports that its 2025 season reached more than 150,000 hackers across 184 hackathons and other programmes, producing over 12,500 projects, and it planned more than 200 student hackathons for the 2026 season. NASA’s International Space Apps Challenge drew more than 114,000 participants to 551 local events in 167 countries and territories in 2025, and judged more than 11,500 project submissions — for ten global awards.

Exhibit 1

114,000+participants in NASA Space Apps 2025NASA · DEC 2025

11,500+Space Apps project submissions judgedNASA · DEC 2025

10global awards for those submissionsNASA · DEC 2025

150,000+hackers across MLH’s 2025 seasonMLH · JUL 2025

NASA figures are for the 2025 Space Apps Challenge; MLH figures are for its 2025 season (events and other programmes). Ten awards against 11,500+ submissions is roughly 0.09%.

Source: NASA (18 Dec 2025); Major League Hacking (8 Jul 2025)

The prizes are the visible part. The less visible part is that hackathons have become a hiring signal, a route into government innovation programmes, and — for many students and career-switchers — the first time anyone outside a classroom judges their work. That raises the stakes on understanding how judging actually works.

And judging is fast. MLH’s organiser guide recommends science-fair-style judging and budgets two minutes for presentation and demo, one minute for questions and scoring, and one minute for the judge to walk to the next table — and tells judges they have about three minutes per team. ETHGlobal gives finalists four minutes to demo and three for questions. Google’s Chrome Built-in AI Challenge 2025 on Devpost asked for a demo video of under three minutes. The UN’s Big Data Hackathon and Datathon allowed up to ten minutes of video — the most generous window here, and still shorter than most team stand-ups.

Exhibit 2

MLH (live, at the table)2 min

Chrome AI Challenge (video)< 3 min

ETHGlobal (live demo)4 min

UN hackathon (video)≤ 10 min

MLH: 2 minutes for presentation and demo within a 4-minute judging slot. ETHGlobal: 4-minute demo plus 3 minutes of Q&A. Chrome AI Challenge: video “should be less than three minutes”. UN: video of no more than 10 minutes.

Source: MLH Judging Plan; ETHGlobal event details; Google Chrome Built-in AI Challenge 2025 rules; UNSD 2022 UN Big Data Hackathon

View data table

Organiser	Format	Minutes
MLH (recommended plan)	Live presentation and demo at the table	2
Google Chrome AI Challenge 2025	Demo video	under 3
ETHGlobal	Live demo (plus 3 min Q&A)	4
UN Big Data Hackathon / Datathon	Video voice-over of presentation	up to 10

The Philippines shows the same dynamics at national scale. The Department of Information and Communications Technology (DICT) runs the Philippine Startup Challenge, which it describes as its flagship annual startup pitching competition, through regional pitching, semifinals and finals; in the 2025 Bicol regional round alone, 46 entries were cut to 11 finalists and one team went to the national round. DICT’s AI.DEAS for Impact 2025 ran regional AI hackathons with the Analytics and Artificial Intelligence Association of the Philippines. And health-data hackathons sit on top of real infrastructure work: in December 2024 PhilHealth and the Department of Health launched a National Health Data Repository to give authorised users standardised, de-identified health data. Hackathons in this setting are not just contests. They are how agencies scout ideas they might actually adopt — which makes “who is this for?” an even sharper question.

A framework: the scorecard, the stack and the sequel

Strip away the branding and every hackathon asks three questions in sequence. Does the project clear the bar? That is the scorecard — the published criteria. Does it stand out from the other projects that also clear the bar? That is the differentiation stack. Does it have a life after Sunday? That is the sequel. Most advice covers only the first. In my experience, winners are decided by the second: the teams that win keep asking what will make them stand out against the other entries. And most of the long-term value — for careers and for the problem itself — sits in the third.

Layer 1: the scorecard

Published judging criteria look different on the surface but converge on five questions. MLH’s standard rules weigh Technology, Design, Completion and Learning equally. ETHGlobal scores Technicality, Originality, Practicality, Usability and a “WOW factor”. Google’s Chrome Built-in AI Challenge 2025 used a pass/fail viability stage and then five equally weighted criteria — Functionality, Purpose, Content, User Experience and Technical Execution — with ties broken by the score for Purpose. The UN Datathon 2023 listed Theme, Innovation, Methods, Presentation and Visualization.

Exhibit 3

	MLH	ETHGlobal	Chrome AI 2025	UN Datathon 2023
Is it a real problem, on brief?	—	Practicality (could its audience use it today?)	Purpose (also the tie-breaker); Stage 1 theme check	Theme
Is the idea original?	—	Originality	Content (creativity)	Innovation
Does it work, and is it hard?	Technology; Completion	Technicality	Technical Execution; Functionality	Methods
Would someone use it?	Design	Usability (UI/UX/DX)	User Experience	—
Can the judge see it quickly?	Demo encouraged; pitches discouraged	WOW factor	Under-3-minute video	Presentation; Visualization

Mapping by the author. MLH and Chrome criteria are equally weighted; ETHGlobal does not publish weights; the UN criteria were labelled tentative. A dash means the organiser has no explicit criterion for that question. The table scrolls sideways on small screens.

Source: MLH Standard Hackathon Rules; ETHGlobal; Google Chrome Built-in AI Challenge 2025 rules; UN Datathon 2023 Webinar 1

Two things stand out. First, no organiser gives points for the size of the build. “Completion” and “Practicality” ask whether the thing works, not how much of it there is. Second, where an organiser has to pick one criterion to break a tie, Google picked Purpose — whether the application solves an existing problem in a compelling way. That is a small rule with a large lesson.

Layer 2: the differentiation stack

Clearing the scorecard gets a team into contention. Among the teams that clear it, four things separate the finalists. I think of them as a stack because each layer depends on the one beneath it.

Exhibit 4

1. 01A sharp userOne named role with one decision or task they struggle with today — not “citizens”, “businesses” or “everyone”.
2. 02Real dataA real or realistic dataset that shows the problem exists and the solution does something with it.
3. 03A working demo pathOne end-to-end path that works live, start to finish, in under two minutes. Everything else can be a mock-up.
4. 04A credible next stepWho would pilot it, what it would need, and what number would show it worked.

Framework by the author. The highlighted layer is the one most teams skip under time pressure.

A sharp user makes every other judgement easier. A judge who knows the product is for a hospital claims officer deciding which claims to audit can evaluate the design, the data and the impact in seconds. A judge told it is “for the healthcare sector” cannot.

Real data is the cheapest credibility in the room. It shows the problem exists, that the team understands its shape, and that the solution does something non-trivial. It also turns “Methods” and “Visualization” criteria from claims into evidence.

A working demo path is the layer most teams get wrong. Not a working product — a working path: one user, one task, start to finish, live. The rest of the product can be a clickable mock-up or a sentence. Judges score what they see work.

A credible next step answers the question every serious judge asks last: “And then what?” It is the bridge from Layer 2 to Layer 3.

Layer 3: the sequel

The sequel is what happens after the event. The evidence (Deep dive 5) shows that most projects stop within a week, and that the factors that predict a short burst of post-event activity are different from the ones that predict survival. A team that has a sharp user and a credible next step has already done half the work of a sequel.

Using the framework as a scorecard

Coaches and teams can use the five questions as a self-audit, scored before the build and again before the pitch.

Exhibit 5

	Score 1	Score 3	Score 5
Real problem, on brief	A technology looking for a use	A sector and a pain point	A named user, a decision they make, and why it is hard today
Original	A tutorial project with a new name	A known idea in a new setting	A fresh angle the judges have not seen today, stated in one line
Works, and is non-trivial	Slides and screenshots	Works on happy-path sample data	One path works live on real or realistic data, including one awkward case
Someone would use it	No interface, or an interface for the builders	Usable with explanation	The user could complete the task without the team in the room
Judge can see it in 3 minutes	Backstory first, demo last (or never)	Clear demo, unclear “why”	User and problem in 20 seconds, demo by 30, next step by the end

Framework by the author. A 1 on “real problem” or “can the judge see it” should trigger a scope change regardless of the total. The table scrolls sideways on small screens.

Deep dive 1: where most teams actually land

Put the two most important layers on two axes — how sharp the user and problem are, and how much of the solution works live — and four archetypes appear. Most hackathon fields contain all four.

Exhibit 6

Good idea, no proofCompelling problem, mostly slides; judges like it and score it low on execution

ContenderA named user, real data, one path that works live, a next step

SlidewareA broad theme, a deck, a mock-up; loses on nearly every criterion

Tech demo in search of a userImpressive build, unclear who needs it; wins “best technical”, rarely the main prize

How much works live →How sharp the user and problem are →

Framework by the author, drawn from mentoring and competing; not a measured distribution.

The mechanism. Problem sharpness and demo strength reinforce each other. A sharp user tells the team which path to make work, so the build is narrower and more likely to work live. A working path, in turn, makes the problem concrete for the judge. Teams that start from the technology end up bottom-right: they build broadly, nothing is quite finished, and the demo becomes a tour of features. Teams that start from the problem but never commit to a build end up top-left.

How to place a team honestly. Ask two questions — the first when the team stops debating and starts building, the second well before the deadline. Can every team member describe the user in one sentence, and give the same sentence? And can someone run the demo path, start to finish, right now — even with fake data? Two yeses put the team on course for the top-right. A no on the first is a scoping problem; a no on the second is a build-order problem.

The failure mode. A common trap is the slide into bottom-right during the night. A team starts with a sharp user, hits an interesting technical problem around midnight, and spends the next eight hours on it. By morning the technical work is impressive and the user has disappeared from the demo.

Deep dive 2: what doesn’t work

The losing patterns are more consistent than the winning ones. Three of them come straight from my own experience as a competitor; the rest are spelled out in organisers’ own rules and judges’ public advice, and the research on pitching and on hackathon projects backs much of it up.

Exhibit 7

	What the judge experiences	Evidence	The fix
Investor pitch in a build contest	A bold vision, little that works	Author’s experience; MLH and ETHGlobal score Completion and Practicality, not market size	Build what can be implemented now; save the vision for the next step
Building big, finishing nothing	Many half-features, none finished	Author’s experience; Nolte et al.: team skills matched project technologies poorly (mean 0.25 on a 0–1 scale)	Plan around the timeline; cut to one path that works; mock the rest
Not knowing your judges	A pitch aimed at the wrong expertise	Author’s experience; evaluator effects are well documented in pitch research (Brooks et al.)	Find out who is judging; adjust emphasis, not substance
Tech demo with no user	“Impressive. Who is it for?”	Chrome AI 2025 breaks ties on Purpose; Devpost judges look for “the problem behind the solution”	Name one user and one decision in the first sentence
Slideware	Five slides of context, a demo in the last 20 seconds	MLH: “Pitches and presentations are discouraged”; ETHGlobal: ≤4 bullets per slide	Demo early; slides only for what cannot be shown
Ignored requirements	Missing video, wrong API, off-theme	Chrome AI 2025 Stage 1 is pass/fail on theme and required APIs	Read the rules first; build a checklist; check it twice
Buzzword stacking	A list of models and frameworks, no mechanism	Jargon impairs processing even when terms are defined (Shulman et al.)	Say what each component does for the user, or cut it
No data story	Charts with no conclusion, or no data at all	UN Datathon scores Methods and Visualization; Space Apps has a “Best Use of Data” award	One chart, one sentence: what the data shows and why it matters
Live demo with no fallback	Wi-Fi fails; the team apologises for two minutes	MLH asks teams to present “even if your hack is broken”	Record a backup video of the demo path; keep it one tap away
Output before the why	A screen with nothing to anchor it to	Author’s practice; ETHGlobal advises about 20 seconds of backstory	A short story of the user and the pain, then the demo

Patterns and fixes by the author; the first three come from the author’s own competing. The evidence column cites the published rule or study behind each where one exists. The table scrolls sideways on small screens.

Source: Author’s experience; MLH Standard Hackathon Rules; ETHGlobal; Chrome AI Challenge 2025 rules; Devpost judges; Nolte et al. (2020); Shulman et al. (2020); Brooks et al. (2014)

Building an investor pitch in a build contest

A hackathon is not a pitch competition, and treating it like one is the first mistake I would warn any team against. Investor pitches reward vision, market size and novelty. Hackathon rubrics reward something else: MLH scores Completion, ETHGlobal scores Practicality — “could it be used by its target audience today?” — and Google scores Purpose. A novel idea built to impress investors tends to arrive as a bold story with very little that works. The vision belongs in the credible next step. The build should be the part that can be implemented now, with the least effort or change for the people who would use it.

Building big

Hackathons are time-bound, and an unfinished big solution is not a valid entry. That single fact explains more losses than any other. Big plans fail in a predictable way: the team divides the work into many parallel features, none of which is finished when the clock runs out, and the demo becomes a tour of screens that almost work. The research suggests why this happens so often. Nolte, Chounta and Herbsleb’s study of 592 Devpost projects found that teams’ self-reported skills matched the technologies their projects needed poorly — a mean “skill matching” score of 0.25 on a 0-to-1 scale — which the authors read as teams being under-qualified for what they attempted, or choosing to learn new technologies on the job. Either way, it is the recipe for the half-finished demo. MLH scores “Completion — does the hack work?”; ETHGlobal scores “Practicality — how complete and functional is your project?” Neither asks how many features you started. Build small, and plan every hour around the timeline.

Not knowing your judges

The same solution lands differently depending on who evaluates it. A panel of statisticians may probe the method; a sponsor’s product lead may ask who would use it; a government panel may ask whether it fits existing processes. Each judge has quirks and specialties, and a team that knows them can put the right evidence first. The research on pitch evaluation (see Deep dive 3) shows how much evaluators’ own lenses shape scores. Knowing your judges does not mean changing the solution for each of them. It means changing the emphasis: which question you answer first, and which piece of evidence goes on screen.

The tech demo with no user

This is the most common pattern among technically strong teams, and the most frustrating to judge. The build is real. The architecture is clever. And the judge cannot score Purpose, Practicality or Usability because there is no one to be useful to. It is no accident that Google chose Purpose — “Are you solving an existing problem in a compelling manner?” — as its tie-breaker, or that one of the Devpost judges interviewed for its judging-tips article said she looks at whether teams “see the problem behind the solution.” Technical excellence without a user tends to win the “best technical” side prize, if there is one, and lose the main event.

Slideware

MLH’s standard rules are unusually blunt: teams are “strongly encouraged to present a demo,” and “pitches and presentations are discouraged.” ETHGlobal advises no more than four bullet points per slide. Slides describe; demos prove. In a two-minute slot, every slide is time not spent proving.

Ignoring the requirements

The cheapest way to lose is to be disqualified before anyone looks at the work. Google’s Chrome AI Challenge used a pass/fail first stage that checked whether an entry “reasonably fits the theme and reasonably applies the required APIs.” Every one of the five judges interviewed for Devpost’s judging-tips article returned to the same point in different words: meet the basic guidelines, hit every requirement, give the required deliverables real time. It sounds obvious, and it is still one of the easiest ways to exit in the first round.

Buzzword stacking

AI hackathons have created a new version of an old problem: the pitch that lists models, frameworks and acronyms instead of saying what the system does. The research on jargon is not kind to this habit. Shulman and colleagues, in a study of 650 adults, found that jargon disrupted people’s ability to process information even when definitions were provided, and lowered their interest and sense of understanding. Judges are experts, and jargon is less costly with expert audiences — but hackathon panels are usually mixed, and the person who decides may be the sponsor’s product lead rather than an engineer.

There is a nuance worth stating carefully. Using many technologies is not itself a losing move: Nolte and colleagues found that each additional technology was associated with 29% higher odds of a project being continued in the week after the event, and a later study by Imam and colleagues of 22,183 Devpost projects found that projects with more technologies were more likely to have their code reused. The problem is not the technology count. It is naming technologies as a substitute for showing what they do.

No data story

Data-heavy hackathons — the UN events, Space Apps, most government challenges — reward a clear analytical narrative. The UN Datathon 2023 listed Methods and Visualization as separate criteria; NASA’s 2025 global awards included “Best Use of Data” and “Best Use of Storytelling”. A team that shows twelve charts without saying what any of them means has handed its data story to the judge, who has three minutes and will not write it for them.

Deep dive 3: the three-minute case

The pitch is where the differentiation stack becomes visible. The research on how experts evaluate pitches is not hackathon-specific, but it is consistent, and it points the same way as the organisers’ rules.

Preparedness beats performance. In a study of business-plan presentations, Chen, Yao and Kotha had 55 investors rate 31 presentations at a university competition. Presenters who appeared prepared — who showed command of the substance — were more likely to win funding; visible excitement did not help. Pollack, Rutherford and Nagy found a similar pattern in televised pitches on Shark Tank and Dragons’ Den: preparedness built what they call cognitive legitimacy, and that drove funding. In hackathon terms, the strongest signal a team can send is fluent command of its own user, data and demo path — not energy.

Experts categorise fast. Elsbach and Kramer’s study of Hollywood pitch meetings, based on 36 interviews and observation of 28 pitch sessions, found that experienced decision-makers sorted pitchers into creative and uncreative “types” using early cues, and then judged the idea through that lens. The first 20 seconds of a hackathon pitch do the same work. A team that opens with a sharp user and a clear stake gets sorted as a contender. A team that opens with “So, in today’s world…” gets sorted somewhere else.

Judges are human, and judging is noisy. Two findings are worth knowing, not because a team can control them, but because they argue for removing every other source of doubt. Bruine de Bruin found that scores in Eurovision and in figure-skating competitions rose with performance order — later performers tended to score higher regardless of the scoring procedure. And Brooks and colleagues found strong presenter effects in pitch evaluation.

Exhibit 8

Narrated by a man68%

Narrated by a woman32%

Experimental respondents, not hackathon judges. In field data from three US pitch competitions the same study found male entrepreneurs 60% more likely to succeed, all else equal. Shown to illustrate that pitch evaluation carries bias, which strong evidence on screen helps to counter.

Source: Brooks, Huang, Kearney & Murray, PNAS (2014), via MIT/REAP (17 Mar 2014)

View data table

Version of the identical pitch	Share of respondents choosing it
Narrated by a man	68%
Narrated by a woman	32%

The practical response to noisy judging is not to perform harder. It is to make the evidence so visible that the judge’s impression has less room to drift: a live screen within 30 seconds, a real record on it, a number that changes.

A three-minute structure that works

My first rule of pitching is to lead with a story: the why is the setup for the what. Showing your output before the judges understand the problem is always a mistake — they are looking at a solution with nothing to anchor it to. The structure below puts that rule into a three-minute slot. It maps to the scorecard in Exhibit 3 and fits the slots in Exhibit 2.

1. 0:00–0:30 — The why, as a short story. “A claims officer at a provincial hospital reviews four hundred claims a week and can audit twenty. She picks by gut.” A user, a pain, a stake. No history of the sector. No team introductions.
2. 0:30–1:40 — The demo path, live. One user, one task, end to end, on real or realistic data. Narrate what the user sees and decides, not what the code does.
3. 1:40–2:20 — The evidence. One chart or one number that shows the solution does something meaningful — and one honest limitation.
4. 2:20–3:00 — The next step. Who would pilot it, what it needs, and what number would show it worked.

Then prepare for questions as seriously as for the pitch. ETHGlobal gives three minutes to Q&A against four for the demo; the questions are where judges test preparedness, and preparedness is what the research says they reward. The three questions every team should rehearse are: “Who exactly is this for?”, “What happens when the data is wrong?” and “What would it take to run this for real?”

Deep dive 4: building and coaching the team

Team size and composition

The evidence on team size is thinner than hackathon folklore suggests. In Nolte and colleagues’ Devpost sample, teams averaged 3.3 members (range two to eight), and the hypothesis that smaller teams would be more likely to continue their projects found no support. Imam and colleagues found that projects with more participants were more likely to have their code reused. The UN Big Data Hackathon preferred teams of three to five and recommended mixing professional and academic backgrounds. Outside hackathons, Wu, Wang and Evans’s analysis of more than 65 million papers, patents and software products found that small teams tend to disrupt while large teams tend to develop existing ideas — a reminder that a hackathon, which rewards a fresh angle, does not need a big team.

What the evidence does support is skill diversity. Nolte and colleagues found that teams with more diverse skills, and with skills that matched what their project needed, were substantially less likely to see the project die in the months after the event.

My team: four people, four distinct jobs

My ideal hackathon team is four people with distinct jobs. Four sits comfortably inside the research and the rules — the UN’s preferred three to five, and close to the Devpost average of 3.3 — but I should be clear that no study I found singles out four as the optimum, and Nolte and colleagues found team size made no measurable difference to whether projects continued. What the research does back is the principle underneath my split: distinct, complementary skills, matched to what the project needs.

Exhibit 9

	Owns	Why the role matters
Main Builder	The core technical solution: the model, pipeline or engine	The hardest work needs protected focus time; everyone else shields it
Doer	Everything around the core: frontend, integration, data prep, wiring the demo, fixing whatever is on fire	The execution engine that turns the core into something you can show
Business / Talker	Problem framing, the story and the pitch	Also the team’s consulter: talks to mentors, coaches and organisers while the builders keep building
Support	Research, slides, testing, documentation, backup demo recordings	Fills the gaps — and keeps the team fed and sane

~50%of the hackathon spent brainstorming — speaking out, discussing and arguing the idea down to its best version before building

The author’s practice from competing and mentoring, not measured data. The roughly 50% thinking share is his rule of thumb; the research cited in the text does not test it. The table scrolls sideways on small screens.

Two features of this setup do most of the work. The first is the time split. I spend about half of a hackathon brainstorming — speaking out, discussing and arguing the idea down to its best version — rather than jumping straight into building. That sounds like a lot when the clock is running, and it is in tension with the build-first instinct most engineers bring. It works only because the second half is spent on something deliberately small: a scoped-down solution that four people can actually finish. The nearest research finding is indirect. Nolte and colleagues found that teams which did technical preparation before the event had about twice the odds of continuing their project in the following week — evidence that front-loaded thinking helps, though it measured preparation before the event, not brainstorming during it.

The second is the Talker. My next priority after the idea is always to talk to the mentors and coaches. They know the criteria, and they know things you don’t. It is always additive: some advice will miss, but you lose nothing, because the Talker consults while the Builder builds. In a team of three, people double up; what matters is that every job has exactly one owner, and that the Main Builder’s focus time is protected.

What a coach actually does

Mentors are tempted to help by coding. It is usually the least valuable thing a coach can do. The advice I give the teams I mentor is the same advice I follow myself:

• Spend the first half thinking, not building. Argue the idea down to its best version before anyone opens an editor.
• Talk to the mentors early. They know the criteria, and things you don’t; the Talker should be in those conversations from the start.
• Scope down to something you can actually finish and implement. An unfinished big solution is not a valid entry.
• Don’t be afraid to pivot late. Even hours before the deadline, a sharper, smaller idea can beat a sunk cost.
• When you pitch, lead with the why before you show the what.

On top of those rules, a coach’s leverage is in questions and timing. Before the build: “Who is the user, in one sentence?” and “What is the one path you will demo?” Once building starts: “Can you run that path end to end, right now?” Scope cuts are emotionally hard for a team and easy for an outsider. And before the pitch: run the full three minutes with a timer, twice.

Preparation, within the rules

Preparation before the event has to respect the rules: MLH’s standard rules say all work on a project should be done during the hackathon, and while a previously considered idea is allowed, reusing prior code or project materials is not. Legitimate preparation is everything that is not the project: researching the user, the domain and the judges, finding public datasets, setting up environments and agreeing roles. Check each event’s rules; they differ.

Deep dive 5: what happens after the hackathon

The prize ceremony is the end of most hackathon projects. The best evidence on this comes from Nolte, Chounta and Herbsleb, who linked 592 projects from 73 Devpost hackathons held between April and May 2018 to their GitHub repositories and tracked commits for five months.

More than half the teams (54%) said they intended to continue. Most did not. The more interesting finding is that short-term and long-term continuation are different phenomena, predicted by different things.

Exhibit 10

35.3%

17.1%

3.6%

Any commit afterBy day 6After 5 months

	Short term (first 6 days)	Long term (to 5 months)
Winning a prize	Strongly associated (odds ratio 6.43 per unit of “weighted win”)	Not significant
Technical preparation	About twice the odds (2.12×)	Not significant
Number of technologies	+29% odds per extra technology	Not significant
Skill diversity in the team	Not significant	Projects reported 71% less likely to be discontinued
Skills matched to the project	Not significant	Projects reported 53% less likely to be discontinued
Intention to expand reach (users, funding)	Not significant	Significantly associated with survival
Intense commit activity in week one	—	Associated with higher risk of being discontinued

Continuation measured as commits to the project’s linked GitHub repository; projects can continue elsewhere without being counted. Collocated hackathons only. Associations, not causal effects: odds ratios from the paper’s mixed-effects logistic regression (short term, days 1–6) and Cox survival model (long term, day 7 to five months). Team size and team familiarity were not significant in either model. The table scrolls sideways on small screens.

Source: Nolte, Chounta & Herbsleb, Proc. ACM HCI CSCW2, Article 145 (Oct 2020)

View data table

Time after the hackathon	Share of projects with commit activity
Any commit after the event	35.30%
By day 6	17.06%
After 5 months	3.55%

Three lessons follow.

Winning gives a project a push, not a future. A prize is associated with a burst of activity in the following days, and then the effect disappears. If the sequel matters, it has to be planned separately from the win.

The post-hackathon sprint is a warning sign. Projects with intense commit activity in the first week were more likely to be abandoned later. My reading — and it is an interpretation, not the paper’s finding — is that a frantic week of polishing is often the team finishing the hackathon rather than starting the product. A short pause to decide who owns what, and for whom, may be healthier than a sprint.

The sequel is about people, not code. Long-term survival was associated with team skill diversity, skills matched to the project, and an intention to expand the project’s reach — finding users, funding or partners. Those are exactly the things the differentiation stack asks for: a sharp user and a credible next step.

Code also lives on in less visible ways. Imam and colleagues traced code from 22,183 Devpost projects and found that only about 9% of the code in those projects was created during the hackathon itself — but roughly a third of that new code was later reused in other projects. Even when a project dies, its parts may not.

This is also where my bias for small, implementable solutions pays off. You will sometimes lose to a flashier output in the room. But a solution scoped to what can actually be implemented, with the least effort or change for the people who would use it, has a far better chance of living beyond the event than an extensive platform that ends up as one of many.

Case examples

DOH-DAP Hack4Health 2024: a sharp user in a crowded field. With more than 100 teams, a health hackathon attracts every flavour of “AI for healthcare.” The winning entry was specific: a fraud-detection platform for unified health data. Fraud detection has a natural user (whoever decides which claims or records to investigate), a natural data story (which records look anomalous, and why) and a natural next step (a pilot on real records). The project was later presented as BANT.AI at a national DOH research forum. The lesson: in a large field, specificity is a differentiator in itself.

UN Big Data Hackathon, youth track: a data story for a global panel. My team placed 2nd and won Best Youth Team, Asia, out of more than 120 teams. The UN’s hackathon runs on data and on video: its published rules ask teams for a presentation, a voice-over video of no more than ten minutes and their code, and youth teams compete from around the world. The UN’s published criteria for its 2023 Datathon put Methods and Visualization alongside Theme, Innovation and Presentation. The lesson: when the judges are statisticians, the data story is the demo.

ICSC Hack-A-Street 2025: a simple model for a concrete question. The winning entry among 13 teams used a gravity model for retail site selection — a classic, interpretable approach that answers a concrete business question: where should the next store go? The lesson: a model a judge can understand in one sentence is easier to score than a more complex one they have to take on trust, and easier to implement afterwards.

DICT AI.DEAS for Impact 2025, Bohol: a vulnerability score for a named place. In a case I was not involved in, a UP Cebu computer-science team won a DICT regional AI hackathon with Aegis, a health data platform that combined health information into a single dengue vulnerability score for Cebu City barangays, explained the factors behind each score and suggested interventions for individuals and hospitals. The lesson: a sharp user (barangay and hospital decision-makers), real data (dengue risk factors) and a clear output (a score with reasons) is a winning pattern well beyond my own teams.

Counterpoints

Implications by stakeholder

Exhibit 11

	Participants	Coaches and mentors	Organisers and sponsors	Hiring managers
The question to ask	Who is the user, in one sentence?	Can they run the demo path now?	Do our criteria reward what we want to adopt?	What did the candidate’s demo prove?
The mistake to avoid	Building the most	Writing the code for them	Criteria that reward slides and scale	Counting trophies, not decisions
What to measure	Seconds until the why is clear	Scope cut before building starts	Projects still active after 3 months	Scope, data and trade-off judgement
Where the leverage is	Real data and a backup video	Questions before the build and the pitch	Follow-up support for winners	Ask what they cut, and why

Framework by the author. The table scrolls sideways on small screens.

For participants

Treat the published criteria as the specification and the differentiation stack as the design. Spend the first half thinking; decide the user and the demo path before you open an editor, and talk to the mentors early. Get real data early. Record a backup video of the demo path before the final hour. And if you win, decide who owns the next step before the celebrations end.

For coaches and mentors

Your leverage is in questions, timing and permission to cut. Use the first half to push the team through the four stack questions; once building starts, check that the demo path runs end to end; time the pitch twice. Tell the team it is never too late to pivot to something smaller and sharper. Resist the urge to fix the build yourself — a team that wins on a mentor’s code has not learned anything it can repeat.

For organisers and sponsors

If you want projects you can adopt, your criteria should say so. Google’s choice of Purpose as a tie-breaker is a good model; so is MLH’s preference for demos over pitches. And if continuation matters to you, the research suggests prizes are not enough: support for winners in the months after the event — access to data, a named contact, a pilot — is what turns a burst into a sequel.

For hiring managers

A hackathon trophy is weak evidence on its own; judging is noisy and team credit is shared. A candidate’s account of a hackathon is strong evidence. Ask what they cut and why, what data they used, what broke in the demo and what happened afterwards. The answers reveal scoping judgement and composure under pressure — the same things that matter in client-facing engineering.

What to do next: a 36-hour playbook

A plan for a typical weekend hackathon, for a team or a coach. Adjust the hours to the event.

Exhibit 12

1. BEFORE THE EVENTPrepare everything except the projectRead the rules and criteria; find out who the judges are; research likely users; find public datasets; set up environments; agree the four roles.
2. FIRST HALFThink, argue, consultArgue the idea down to its best version. The Talker consults mentors early. Write the one-sentence user, the single demo path and the rules checklist.
3. HALFWAYCommit to a small buildScope down to what the team can finish and implement. Main Builder on the core; Doer on the demo wiring; Support on research and testing.
4. SECOND HALFBuild the one pathMake it work end to end on real or realistic data; mock the rest. Pivot if a sharper, smaller idea appears — even late.
5. LAST HOURSHarden, record, rehearseOne awkward case handled; one chart, one sentence; backup demo recorded; the pitch run twice with a timer — why before what.
6. AFTERPlan the sequel, then pauseName an owner, a user to talk to and one number to move. Avoid the frantic week-one sprint.

Framework by the author. The roughly 50% thinking share is his rule of thumb, not a tested finding. Preparation before the event must respect each event’s rules on prior work.

The pre-flight checklist, to be answered in writing before the team starts building:

1. Who is the user? (One role. One sentence.)
2. What decision or task do they struggle with today?
3. What data will we show, and where does it come from?
4. What is the one demo path, start to finish?
5. What will we not build?
6. Which criteria and requirements must we meet? (Copied from the rules.)
7. What is the next step if we win?

If a team cannot answer questions 1, 4 and 5, it is not ready to write code.

Limitations and methodology

• The continuation evidence is old and narrow. Nolte and colleagues studied 592 projects from 73 Devpost hackathons over one month in 2018, mostly collegiate and all collocated. Continuation was measured as commits to a linked GitHub repository, which misses projects that continued elsewhere. Online and AI-era hackathons may behave differently.
• Associations are not causes. Winning, preparation and skill diversity are associated with continuation; the study does not show that they cause it. Teams that win may differ in many unmeasured ways.
• Judging criteria vary by event. The four organisers in Exhibit 3 are a convenience sample of well-documented events, not a representative survey. The UN criteria were labelled tentative, and ETHGlobal does not publish weights.
• The pitch research is mostly not about hackathons. The preparedness, categorisation, order-effect and bias studies come from investor pitches, film pitches and arts competitions. I use them as analogues; their effect sizes should not be assumed to transfer.
• The Philippine examples are illustrative. Public documentation of Philippine government hackathons is patchy; I have cited only what organisers or universities published, and could not find published judging criteria for those events.
• My frameworks and practice are mine. The scorecard mapping, the differentiation stack, the archetypes, the rubric, the four-role team, the roughly 50% thinking split and the playbook come from competing in and coaching hackathons. They are tools for thinking, not validated instruments, and my own results are a small, self-selected sample. Where my practice meets the research — team size, front-loaded thinking — the research is consistent with it but does not test it directly.

Build less, prove more

Hackathons reward a particular kind of courage: the willingness to build one thing that works instead of ten things that might. The published criteria, the time limits and the research on how experts judge pitches all point the same way. Judges score what they can see working, for someone they can picture, in the few minutes they have. And the projects that outlive the weekend are the ones whose teams knew, before the build, who they were building for and what would come next.