What hackathons have taught us

We have been on both sides of a hackathon: trying to finish a project before the deadline, and trying to make the event work for everyone else.

The deadline helps people start. What we provide around it determines how much they can learn and whether they have a reason to keep going.

Make the first hour useful

Before a team can build, it needs a problem it understands and tools it can run. A broken setup can consume the energy someone arrived with.

Give people a working starter, explain where to get help, and make the first milestone small. Mentors should help teams reduce scope while keeping a complete user flow.

The research-backed Hackathon Planning Kit treats mentoring, team formation and continuity as decisions to make before the event. A useful challenge needs more than a prize and a countdown.

Make room for learning by doing

A meta-analysis of 225 undergraduate STEM studies found that active learning improved examination performance. Average failure rates were 21.8% with active learning and 33.8% with traditional lecturing in the studies reporting that outcome.

Those are classroom findings, not hackathon success rates. They support taking participation seriously when designing a workshop: let people try, receive feedback and try again. Watching someone else build is a different experience.

Tell people what a good result looks like

If user feedback matters, give teams time to find a user. If a working demo matters, mentors should help people finish one small flow before expanding it.

The GOV.UK usability-testing guide is useful here. Ask someone to attempt a relevant task and observe where they get stuck. A demo that survives an unfamiliar person's question teaches more than one that only works with its creator narrating every click.

We also want time for team formation and conversations after the demos. An event should leave people with collaborators as well as code.

Design for the week after

A 2020 study of 78 hackathons found different factors associated with short-term and longer-term project continuation. Technical preparation and winning were linked to short-term continuation; skill diversity, skills matched to the technology, and plans to expand a project's reach mattered for longer-term continuation.

It was an observational analysis of recorded projects, not proof that a particular event format causes retention. It does show why a prize-day result is an incomplete measure.

Before the final demo, ask each team what comes next and what might block it. Make the repository, setup instructions and contact details easy to find.

For future Arandano events, we want a 30-day follow-up asking which teams kept building, whether anyone used the project, and what help they need. We should publish the response rate alongside the results. This is a measurement plan, not a retention claim.

The next challenge is on our calendar. We want people to leave with work they can show and people they can keep building with.

Read more

• Hackathon Planning Kit. Research-informed guidance on goals, mentoring, team formation and follow-up.
• Nolte, Chounta and Herbsleb, What Happens to All These Hackathon Projects?, 2020. Evidence on project continuation after the event.
• Freeman and colleagues, Active learning increases student performance in science, engineering, and mathematics, 2014. A large review of learning through participation in STEM classrooms.
• Falk and colleagues, The Future of Hackathon Research and Practice, 2022 preprint. A research agenda covering event design, inclusion and the purposes of hackathons.
• GOV.UK, Using moderated usability testing. A practical method for testing a prototype with a likely user.
• NSF, I-Corps 2025 biennial report. Further reading on customer discovery and what happens beyond a technical prototype.