How to Win a Hackathon: Scope, Demo and Submission Day

Nobody can promise you a win. Judges are human, fields vary, and luck plays a part. But there is a pattern in what separates a project that gets noticed from one that doesn't, and it is mostly not raw coding talent. It's reading the brief, cutting scope and presenting well.

Start with the scorecard, not the idea

Before brainstorming, find the judging criteria on the event page or in the official rules. Write them at the top of your notes. Typical ones are originality, technical execution, design, potential impact and use of the sponsor's tools, but yours will be specific to the event.

Then ask which of those you can plausibly be strong at in the time you have. If "impact" and "clarity of demo" are weighted heavily, a polished, simple tool beats a half-working technical marvel. If you can't find criteria at all, that is worth knowing before you invest a weekend (see our legitimacy checklist).

Understand what the sponsor wants

Sponsors fund hackathons for a reason. A company with an API wants to see people building with it. A cloud vendor wants usage. A platform wants showcase projects it can point at. Look at the sponsor's announcement and the prize categories, and the goal will be obvious.

So use the sponsor's product in a way that is central to your project, not bolted on. A judge from the sponsor's team will notice the difference in about ten seconds. Also look for special prize categories. A "best use of X" prize often has a much smaller field than the grand prize, which is the same idea as the odds ranking on our site: prize money divided by competition.

Pick one problem and one user

The most common mistake is trying to build a platform. Choose one person with one problem, and build the shortest path that solves it. Examples of the shape, not specific ideas: "a tool that turns a pile of receipts into a tax-ready spreadsheet," not "an AI finance assistant."

A useful test: can you explain it in one sentence without the word "and"? If not, cut something.

Scope for a working demo

Judges mostly see a few minutes of your project, so the demo is the product. Plan backwards from it.

1. Define the demo path first. Write the three or four steps a viewer will see, from opening the app to the payoff.
2. Build that path end to end before polishing anything else, even if the pieces are crude.
3. Fake what you can. Hardcoded data, a stubbed login and a canned example are fine if you say so honestly. Don't fake the core idea.
4. Freeze features with several hours to spare. New features at the last minute break the demo.
5. Keep a fallback. If a live service might go down, record a version that doesn't need it.

A small thing that works beats a large thing that nearly works. Every time.

The demo video

Many online events require a short video, and some won't judge a project without one. Check the maximum length and where it has to be hosted. Some rules I've seen ask for two minutes or less, others allow more, so read yours.

A structure that works:

• Seconds 0 to 15: the problem and who has it, in plain words.
• Next stretch: the product in use. Show it, don't describe it.
• Short close: what you built it with, what is next, and where to find it.

Practical tips: record audio on a decent mic or a quiet room, use a screen recorder at readable resolution, write a short script and read it, and cut anything that is slow. Watch it once with the sound off to see whether the visuals make sense alone. Don't use copyrighted music; some rules specifically forbid it.

The written submission

Judges often skim. Make the write-up scannable.

• One-line summary at the top.
• The problem, the solution and how it works, in short paragraphs.
• Which sponsor tools you used and how, with specifics.
• What is real and what is mocked.
• A link to a working demo or a clean, public repo with a README that explains how to run it.
• One or two screenshots, if the platform allows images.

Mention what you would build next, in a sentence or two. It signals that you have thought past the weekend.

Submission-day checklist

Submit early. Platforms get slow at the deadline, and time zones catch people out. Run through this list a few hours before the cutoff.

1. Confirm the deadline in your own time zone.
2. Does the demo work from a clean browser or a fresh clone of the repo?
3. Video uploaded, public or unlisted as required, and the link opens when you are logged out.
4. Repo is public (if required) and contains no API keys or passwords.
5. Write-up proofread, with every required field completed.
6. Every team member is listed on the submission, and each one accepted the rules if the platform asks.
7. You have selected the special prize categories you want to be considered for.
8. Take a screenshot of the confirmation.

Then, if time remains, submit a draft first and improve it. Many platforms let you edit until the deadline.

After you submit

Share the project, thank your teammates, and message the sponsor contacts you met. If you did not win, ask for feedback if the organizers offer it. Each event teaches you which criteria you handled well. If you are short on teammates for the next one, our post on finding teammates is a good next step, and the online hackathons list is a decent place to practice.

Search 405 live hackathons