Judging can feel like a black box. You pour your heart into a project, present it in front of a panel, and then... someone else wins. What happened? Was your project not good enough? Was it politics? Was the other team just louder?

Usually, it's none of those things. Judging at hackathons follows patterns, and once you understand those patterns, you can work with them rather than against them. Let's pull back the curtain.

Most hackathons score projects on four or five criteria. The exact wording varies, but they almost always boil down to some version of these:

Each criterion is typically scored on a scale (1–5 or 1–10), and the scores get combined — sometimes with equal weighting, sometimes with certain criteria weighted more heavily. Many events publish their rubric in advance. If yours does, read it. If it doesn't, ask the organisers. This is not secret information.

Behind the rubric, judges are really asking themselves five questions:

1. Did you solve a real problem? Not a hypothetical one. Not "what if someone needed to track the migration patterns of butterflies using blockchain." A real problem that real people have. The more concrete and relatable the problem, the better. Bonus points if you've experienced the problem yourself — that authenticity comes through.

2. Does your solution actually work? This is huge. A simple demo that runs smoothly and does one thing well will outscore a complex, ambitious project that crashes during the presentation. Judges know you only had a day or a weekend. They're not expecting a production-ready app. But they do expect it to function.

3. Can you explain it clearly? If the judges don't understand what you built, they can't score it. Full stop. This is where many technically brilliant teams lose. You might have the most elegant architecture in the room, but if your explanation is confusing or jargon-heavy, judges will score you lower — not because they're unfair, but because they genuinely can't evaluate what they can't follow.

4. Is there a "wow" moment? Something surprising, clever, or delightful. Maybe it's an unexpected use of a technology. Maybe it's a small design touch that makes people smile. Maybe it's the sheer ambition of what you attempted. The "wow" doesn't have to be technical — it can be in the concept, the storytelling, or the user experience.

5. Did you use the time well? Judges deeply appreciate scope discipline. A team that says "We intentionally kept it focused on one use case and nailed it" impresses more than a team that says "We tried to build everything and ran out of time." Knowing what to leave out is a skill, and judges recognize it.

Here's the liberating part. Judges genuinely do not care about:

A typical rubric might look like this:

If innovation and technical execution together account for 50% of the score, that tells you where to invest your energy. If presentation is weighted at 15%, that's still the difference between winning and placing third — don't skip your practice runs.

This is the most strategic thing you can do. Once you know the criteria, actively design your project and demo to hit each one:

Many hackathons offer multiple prize tracks beyond the grand prize. "Best Social Impact." "Most Creative Use of [Sponsor API]." "Best First-Time Hacker Project." "Best Use of AI."

These are real opportunities, and they're often less competitive than the main prize. If your project naturally fits a category track, lean into it. Mention the sponsor's tool in your demo. Frame your impact through the lens of that category. Some teams even choose their project idea specifically to target a category prize — and that's a perfectly valid strategy.

Check the prize list before you start building. It might shape your project in a way that gives you a much better shot.

Here's the honest truth: judging is subjective. Different judges value different things. A panel of investors might prioritize business viability. A panel of engineers might prioritize technical depth. A panel of designers might prioritize UX.

Sometimes the "best" project doesn't win. That's okay. It doesn't mean the judging was wrong — it means multiple projects were strong and the judges had to make tough calls with limited information and limited time.

Focus on what you can control: build something real, make it work, tell a good story, and hit the criteria. That puts you in the best possible position, regardless of the outcome.

Key takeaways: