I've participated in many hackathons, as a hacker, mentor and judge. I've won over $20k in prizes, and some of those projects became real companies.

I've come to learn that there are many you can take from a hackathon, outside of the obvious learning experience, as someone trying to build a company.

We obsess over market validation, fast prototyping, and quick iteration. A technical hackathon compresses all three into a weekend: you build a working demo, get immediate feedback from sponsors, judges, mentors, and other hackers, and prize money itself becomes a signal that something might be worth pursuing.

This blog walks through the three phases of a hackathon: before, during, and after, and how to make the most out of it.

Before: The Setup

Pick the right hackathon

Pick a hackathon in the industry you're targeting, that could be AI, biotech or crypto. You want one with a strong sponsor pool and judges relevant to the product you want to prototype. It'll also be the kind of hackathon where you could meet your co-founder(s).

I've gone to a lot of ETHGlobal hackathons because my projects revolved around identity and decentralized finance, two subjects that matter in that ecosystem.

Team composition

I'm a proponent of either going with people you know, or hacking solo.

You could find teammates there but it's usually much better to work with people you've already worked with, as it'll be easier to align ideas and share the work. Nothing stops you from teaming up with someone you met at a previous hackathon; the important part is that you've seen their work in the past.

This applies to founders in general: if you want to test a potential co-founder relationship, build something unrelated to your main ideas with them first, that's a great use of a weekend that could save you from trouble down the line.

Sponsor reconnaissance

Do some sponsor reconnaissance before choosing your hackathon. Check what kind of projects they want, what technologies they're pushing: is it compatible with the prototype you had in mind? Does it require all your energy?

Generally I think it's better to come with a few project ideas you're excited about, that you can build in a weekend, and layer sponsor prizes on top. A sponsor judge will almost always prefer a great project that integrates their technology lightly over a generic project that focused on integrating all their features. These judges have seen every generic project you can think of; anything original already has an edge.

You can also choose one sponsor and build specifically for them if you don't have a project in mind. That's not my experience because I've always used hackathons to prototype my own ideas. If you go this route, look for undersubscribed sponsors where you'll have fewer competitors.

Choosing a project

For example, in a hackathon where we built a project called Proof of Passport, we spent the first few hours doing a feasibility check: figuring out if we could extract a governmental signature from passports. That's my usual approach: come with several ideas, then use the first hours to narrow down based on what's actually buildable.

When choosing, you want:

  • A strong demo: something you can show working in front of judges, ideally in a way that makes it obvious it works
  • Something immediately useful: the judges could use your demo themselves if they wanted. Avoid projects where you'd have to say "imagine this or that", like anything requiring a network effect to be useful (a social network, a marketplace, etc). It's not impressive to show a basic demo and say it would be awesome if 100k people signed up. It's much more impressive if it's useful with just one user.
  • Something pitchable: an idea you can explain in one sentence. Don't hesitate to do early research by pitching to sponsors, mentors, and other hackers before you commit.

Steps recap

  1. Pick your hackathon: Industry match? Strong sponsor pool? Right crowd for co-founders?
  2. Assemble your team: People you've worked with, or go solo.
  3. Scout the sponsors: Which tracks are undersubscribed? What tech do they want to see?
  4. Come with ideas: 2-3 project concepts you're excited about.
  5. Validate early: First hours: feasibility checks. Can you actually build this in a weekend?

Note on ideation: you'll make use of AI for building, but please do not use it for generating your ideas, at best you can test your own ideas against LLMs but your ideation should come from you, your experiences, your taste.

During: Demo-Driven Development

I consider the "during" to start when you've decided what to build, even if the official timer has already started. If you haven't decided yet, you're still in the "before".

So now you have an idea for your prototype. At this point you should only focus on one thing: what demo are you going to show to the judges? Figure that out and remove everything else. Your only job for the rest of the hackathon is to get that demo working. Anything the judges won't see should not be built.

I'd argue this part - going from idea to scoping the demo - is the most important part for winning. More than actually building it. Because this is when you determine what you'll show and how much work it'll take. Pick the smallest thing that demos well.

Plan your workload if it helps you scope better; be realistic. If you have a team, this is the moment to separate tasks. Aim for your scoped demo to be ready by 50% to 75% of the deadline. Having that margin helps you when you hit obstacles like bugs or opinions changing your demo. You also need time to prepare your submission: the pitch, a demo video, and a live demo.

It's demo-driven development: start with the pitch, then backfill. If you have any doubt about what to do next, go back to the demo.

Try to have at least one or two sponsors in your project, but remember they're additions to a great demo, not the bulk of it. Stack them at the end if you have time, but don't compromise your demo for them.

Steps recap

  1. Define the demo: What will you show to judges? Write it in one sentence.
  2. Cut/Scope: Remove anything the judges won't see.
  3. Timeblock backwards: If deadline is Sunday 9am, work back: submission prep (2h), polish (2h), buffer for bugs (3h). What's left is build time.
  4. Build the pitch first: Can you explain it in 30 seconds? If not, scope is too big.
  5. Check at 50% — Halfway through, ask: "Can I demo this right now?" If no, cut more or be willing to not finish (if the features you're working on are necessary).

Tools for the weekend

You'll want to take advantage of AI tools to help you prototype faster, but avoid using them for generating ideas, this should come from you.

Visualize first: Stitch (Google), v0, Figma, Excalidraw, Napkin.ai for mockups and diagrams.

Then build: Cursor, Claude Code, OpenCode, GitHub Copilot for AI coding. Vercel, Replit, Railway for fast deploys. Loom or Screen Studio for demo video.

After: Make the most out of it

By this point I hope you've won some money, and more importantly if you're a founder, you have an early product you can keep working on.

If you do, make the best of the post-hackathon by following up with sponsors. Those relationships are worth more than the prize money. You could get grants from them, or a job. You could be selected to present your project at future hackathons, that's what happened with our BackupBuddy project. You could receive VC attention, that's happened with most of my hackathon projects.

Also keep in touch with other hackers. Form teams for the next one. Find co-founders from a pool of people who've been in the same boat as you.

Whatever result you end up getting, you can always win the hackathon for yourself.

Pick the right one, scope aggressively, let the demo drive everything, and follow up. Some of those weekend projects might become your next company