How we read a hackathon like a sponsor's showcase
A practical, first-person strategy guide to judging rubrics, prize stacks, and eligibility gotchas. How we decode what a hackathon is really rewarding before we write a line of code.
By doom2quake, a human builder collective.
Most teams read a hackathon page for the prize number and the deadline. We read it for the intent. Almost every hackathon is a sponsor’s showcase. The sponsor is paying to see their product used well, and the rubric is how they tell you that out loud. When we decode that intent first, the build almost designs itself.
Here is the lens we bring to every event, before we commit to entering.
1. The rubric is the spec
The judging criteria are not a formality. They are the actual specification of what wins, weighted. So we treat them literally.
- Read the weights, not just the categories. “Technical difficulty (40%), design (20%), impact (20%), presentation (20%)” is a completely different event from the same four categories at “10 / 30 / 30 / 30.” The first rewards a hard technical core. The second rewards a polished, well-pitched idea. We build to the weights.
- Find the category we can max out. We would rather score 90% on the heaviest criterion than 70% across all of them. Judges score fast. A submission that is obviously excellent on the thing that matters most beats a balanced but forgettable one.
- Watch for the criterion that is secretly a gate. “Working demo required” or “must run live” is not 10% of the score. It is pass/fail. We identify these and protect them first.
2. The prize stack tells you who the judges are
A single grand prize and a stack of sponsor-specific prizes are two different games.
- Sponsor track prizes reveal the real ask. “Best use of [Sponsor] API” tells you exactly what the sponsor wants to see demoed. If a track prize is large relative to the grand prize, that track is the hackathon.
- Stackable prizes change the math. When you can win the grand prize and multiple sponsor prizes with one project, the highest-value move is a build that legitimately hits several sponsor tools at once, not as bolt-ons but as a coherent product.
- Count the seats. Ten prizes across fifty serious teams is a very different bet than one prize across five hundred. Prize breadth relative to the likely field size is a real signal of expected value.
3. Eligibility gotchas that quietly disqualify
The fastest way to lose is to build something great that does not count. We check these every time.
- Region and residency. Some prizes are restricted to certain countries or exclude them for legal reasons. A remote-open hackathon can still have region-locked prize money.
- Team size and prior work. Caps on team size, bans on pre-existing code, “must be built during the event” clauses, and open-source license requirements are all common and all disqualifying if missed.
- Original versus submitted-elsewhere. Many events forbid projects submitted to other hackathons. If we are running a season, we make sure each build has a clean home.
- Registration versus submission deadlines. These are often different dates. Missing the registration window can lock you out even if the submission deadline is weeks away.
- Demo and repo requirements. A public repo, video length limits, a specific submission form, a required “how I built this” section. We make a checklist and clear it before the deadline, not on it.
4. Study what won last time
If the event has run before, past winners are the single best source of truth about how judges actually scored, which is often subtly different from the written rubric. We look at the level of polish, the scope, whether winners leaned technical or narrative, and how they framed impact. Then we aim one notch above that bar.
5. Decide to not enter, on purpose
The discipline that compounds is passing on the wrong events. If the rubric rewards something we cannot credibly max out, the field is enormous, the eligibility is a poor fit, or the timeline collides with a better bet, we skip it. Saying no to the wrong hackathon is how we say yes to the right one with our whole effort.
We keep every event we have decoded (prize stack, rubric weights, eligibility notes) in our hackathon knowledge graph, and the same lens shows up in our build writeups. If you want the working example, read how we built Atlas. The rubric read came first, the code came second.