Here is the single most common mistake hackathon teams make: they try to build too much.

It happens every time. A team gets excited about their idea, brainstorms a dozen features, sketches out an ambitious architecture, and then spends the entire event frantically building something that's 20% finished and doesn't really work. Meanwhile, the team next to them built one simple thing, polished it until it shone, and walked away with the prize.

The teams that win hackathons aren't the ones with the biggest ideas. They're the ones who scoped the smallest, most achievable version of their idea and executed it well.

Here's a number to tattoo on your brain: teams accomplish about 25% of what they plan. That's not pessimism — it's a consistent observation from hackathon organisers, mentors, and judges across hundreds of events.

You will lose time to setup. You will lose time to debugging. You will lose time to team discussions, meals, fatigue, Wi-Fi issues, API documentation that lies, and the inevitable moment where someone says "wait, I think we need to rethink this part."

So whatever you think you can build, divide it by four. That's your actual scope. If that sounds depressing, flip it around: if you plan for 25%, you'll actually finish what you set out to do. And finishing feels incredible.

You've probably heard the term MVP — minimum viable product. At a hackathon, think of it as minimum viable proof. You're not building a product. You're building evidence that your idea could work.

Ask yourself: what is the simplest possible version of this idea that would make a judge say "oh, I get it — that's clever"?

That's what you build. Nothing more.

Strip away the login system. Strip away the settings page. Strip away the edge cases. Strip away the second and third user types. Get down to the absolute core of your idea and build just that one thing.

The best scoping technique is almost brutally simple. Answer three questions:

If you can build that one flow and make it feel good, you have a demo. A demo is all you need.

Everything else — multiple user types, additional features, robust error handling, responsive design — is decoration. Nice to have, but only after the core flow works perfectly.

This is a mindset shift that separates experienced hackathon builders from first-timers. Your project needs to look like it works. It doesn't need to actually handle every scenario.

Hardcode things. Use dummy data. Fake the parts that aren't core to your idea. If your concept is an AI-powered recipe suggester, spend your time making the suggestion experience feel magical — don't spend three hours building a user registration system that nobody will ever see during your demo.

Judges evaluate the idea and the execution of the core experience. They're not going to try to break your app. They're not going to test edge cases. They want to see the one thing your project does well.

Build for the demo. Build for the "wow" moment. Cut everything else.

When your team is brainstorming features, use this simple framework to sort them:

Must have — Without this, the demo doesn't make sense. This is your core flow, your one big idea made tangible. If you only build the "musts," you should still have something worth presenting.

Should have — These make the demo better but aren't essential. A nicer UI, a second screen, a small extra feature that strengthens the story. Build these if you have time after the musts are solid.

Could have — The wishlist. The "wouldn't it be cool if..." features. Write them down so you don't forget them, then ignore them. You almost certainly won't get to them, and that's fine.

Be honest with yourselves during this exercise. The natural temptation is to label everything as "must have." Push back on that. If your demo can still tell its story without a feature, that feature is a "should" at best.

At the halfway point of the hackathon, stop and assess. Look at your remaining feature list — the things you haven't built yet. Now cut it in half.

This sounds painful, and it is. But it's the single best thing you can do for your project's quality. The second half of a hackathon is always slower than the first. You're tired. The bugs get harder. Integration takes longer than expected. And you still need time to prepare your presentation.

Cut aggressively at the halfway mark. Protect your time for polish and presentation prep. A smooth demo of a small project will always beat a buggy demo of a big one.

Judges have seen hundreds of hackathon projects. They know what "tried to do too much" looks like — it's the team that apologises during their demo, clicks through broken screens, and says "this part isn't working yet, but imagine if..."

They also know what "nailed the scope" looks like — it's the team that walks up confidently, shows one clean flow, gets a reaction from the audience, and finishes with time to spare.

A polished small thing communicates competence, clarity of thought, and good judgement. A broken big thing communicates ambition without execution. In hackathons, as in startups, execution is everything.

Build less. Build it well. That's the whole secret.

Key takeaways: