Skip to content
Chapters

Hackathon and after

How a Colosseum hackathon is won

What Colosseum judges look at, what winners do, and how to present.

A summary of what Colosseum publishes in How to win a Colosseum hackathon and of what we see as judges.

What the judges look at

  • Teams that will keep building full-time, with a business model.
  • A working demo on devnet. Not a video of what should happen.
  • A real problem, with a market. Founder–market fit.
  • Products that enable markets that could not exist without crypto.

What the winners do

  • Teams of 3+, technical and non-technical. Use Colosseum's Cofounder Directory.
  • Problems they know up close; ten-year ambition, not a quick pivot.
  • Three quarters of the time on engineering, whatever the length. They prioritise the features that produce the "aha".
  • Build in public: show progress on X every week, ask for feedback before spending.
  • The last week for testing and polishing the presentation.

Common mistakes

  • Underestimating team coordination.
  • Building more than fits in the demo.
  • Not talking to users during the sprint.
  • Presenting without community validation.

The presentation

  • Read this edition's rules in the first week, not the last: eligibility, prior work allowed, video format, repo permissions and the closing time with its timezone.
  • A video under 3 minutes: the team, the product with a demo, the market and how they get users, why this problem.
  • A repo with the scope documented; a working implementation on devnet.
  • Being able to say in one sentence why that part goes onchain — and what they decided to leave out.
  • Understand the business: who pays, why, how much. Global potential: it should work in another country. Beyond your own problem: what other problems the same application solves.

Reading