How to Win Hackathons: Lessons from Seven Years

Hackathons put a clock on everything, which makes them look like coding races. The teams that place tend to make a useful idea easy to see and hard to forget.

_Hero image: aql's post celebrating the Leeds Smart Cities Hackathon win._

I learned this across four competitions that had almost nothing in common. My team won the Bounce Corruption Hackathon in 2017 and took second place at Hack Agric in 2018. That same year, I finished in the top 20% of 138 teams in a Data Science Nigeria machine-learning competition. Six years later, we won the Smart Cities Hackathon in Leeds.

Civic technology. Agriculture. Machine learning. Smart cities. Different problems, same pressure: choose what matters and get it working before the deadline.

A technically impressive solution can still lose if nobody can explain why it matters. Before discussing architecture, get the team to complete this sentence:

For this specific user, who struggles with this costly problem, we make this important outcome possible by this clear mechanism.

If the sentence contains three users, five problems or a page of caveats, you still have several ideas. Keep narrowing until another person can repeat it after hearing it once.

That was the turning point for our Leeds team. "Smart cities" was far too broad, so we focused on one decision inside Stop the Traffik: moving from intelligence signals to faster human action. We left the rest alone. The judges could see the problem, follow the demo and understand what would change for the analyst using it. The prototype and technical approach became the evidence, not a slide full of promises.

Before I commit to an idea, I ask:

• Would somebody care if this worked?
• Can we name the user, the moment and the constraint?
• Can we show the improvement in a short live demo?

If two ideas survive, pick the one where your team already has a head start. Domain knowledge, realistic data or experience with the technology will save hours.

Hackathon teams often lose time building the edges of a product: authentication, settings, dashboards, integrations and infrastructure that never appear in the final pitch. Judges cannot reward invisible effort.

I call the one path that must work the golden path. It begins with the user's problem and ends with a visible result:

1. A user submits or selects one realistic input.
2. The system performs the one technically meaningful action.
3. The user sees an outcome that is clearly better than the old way.

Build that path before adding anything else. A narrow working flow is more persuasive than six disconnected screens. Experienced Devpost judges make a similar case: the strongest entries feel finished and score across the rubric instead of betting everything on one clever feature.

The leaderboard taught me this brutally. A model that does not produce a valid submission scores nothing. So I got a baseline working, kept the pipeline reproducible and then improved what would move the score. I still use that order: working result first, optimisation second.

Ask this before anyone writes code:

What must the judges see to believe our central claim?

The answer tells you what to build. If a farmer should make a better decision, show the decision before and after your intervention. If analysts should identify risk faster, show a signal becoming a recommendation they can act on. If the claim depends on scale, prepare a realistic dataset and separate what you tested from what you projected.

I learned to ask it early because infrastructure can swallow the whole event. You can spend hours building a sound system and still end up with a demo that hides the value.

Write four lines before you build: the claim, the evidence that supports it, the action you will perform on screen and the backup you will use if the live environment fails.

Be honest about the edges. Label simulated data, mocked integrations and projected results. Judges trust the demo more when they can tell what works now and what you would build next.

A prototype does not speak for itself. Without context, judges see screens and clicks rather than the problem you solved.

My pitch order is simple:

1. Open with one person in one difficult moment.
2. Explain why the current approach lets that person down.
3. Demo the shortest route through your golden path.
4. Show what changed and why the result is credible.
5. Name the next extension, risk or validation honestly.

Spend most of the presentation on the problem, demo and proof. Avoid long team introductions and feature inventories. Name the technologies only when they explain a meaningful choice: speed, privacy, cost, accuracy or feasibility.

The Devpost guide to successful hackathon demos recommends the same simple story: explain the problem, show what the hack does and make the impact clear. Judges experience the submission page, screenshots and video as part of the project, so do not leave them until the end.

Rehearse with a timer and a person who did not build the project. If that person cannot explain the value afterwards, simplify the story. If the demo requires narration to hide confusing steps, simplify the product.

Teams move faster when they spend less time coordinating.

At the start, decide who owns the problem and final story, who owns integration and who keeps testing from a clean starting point. Give the other builders bounded components with clear inputs and outputs. On a small team, one person may cover two roles. Write the ownership down so nothing falls between people.

Use short checkpoints only to surface blockers and integration risk. Skip status meetings where everyone narrates activity.

Protect the final quarter of the event. Stop adding features. Test the exact presentation path, prepare the submission, check every link and rehearse the questions. Then make a fallback. I would rather cut a feature at this stage than present a clever project that breaks on the first click.

For a one- or two-day event, I work in four phases.

• Read the rules and convert every judging criterion into a question your demo must answer.
• Research the problem enough to identify a specific user and constraint.
• Write the one-sentence problem statement.
• Agree on the golden path and the proof the judges need to see.
• Choose tools the team can ship with, not tools it wants to learn under pressure.

• Create the thinnest end-to-end version, even if parts are mocked.
• Put it in the presentation environment early.
• Draft the submission title, one-line description and story.
• Write down your assumptions. Test the risky ones during the event.

• Replace the riskiest mock with working technology.
• Test integration as you go. The final hour is too late.
• Capture screenshots and short clips whenever the build is stable.
• Delete anything that does not strengthen the central claim.

• Freeze features. Really.
• Test from a clean device, browser session or environment.
• Rehearse the pitch and questions against the actual time limit.
• Submit early. Spend the remaining time on reliability and clarity.

The prizes were useful. The habit outlasted them. I now start messy projects by narrowing the problem, making the trade-offs visible and deciding what has to work first. Hackathons taught me that.

Those four results did not depend on one framework or one type of challenge. Every team made the same three decisions: make the problem specific, build the smallest proof that works and tell the story without hiding the gaps.

Pick a challenge from the Devpost hackathon directory. Write the one-sentence problem before you open an editor, then sketch the three-minute demo your team intends to deliver. You will save hours.