Hackathon Tips: What Repeat Winners Do Differently

A hackathon isn’t a 48-hour sprint, even though most teams treat it that way. It’s a multi-day arc that runs roughly three days of prep, two days of build, and a long stretch afterwards if your team is selected as a winner. Treat the event as a sprint and you’ll end up burning either the prep window, the demo, or both.

These hackathon tips come from the developers who keep placing across the 450+ events we’ve run. When we ask the repeat winners what they do differently, the same answers come back. Below are ten of those answers, organised into the three phases that actually decide the outcome: before the event, during the build, and the final stretch to demo.

Hackathon Tips for Before the Event: 4 Pre-Event Moves That Decide Winners

Most teams lose in the first two hours of a hackathon, not the last, because the decisions that put a team on the leaderboard are usually made in the week before the kickoff when nobody else is paying attention. Four pre-event moves come up repeatedly in winners’ accounts.

Tip 1. Read the judging rubric before the problem statement

The rubric tells you what gets rewarded, while the problem statement only tells you what to build, and most teams confuse the two when they should be reading them in order.

• A 40% weight on “innovation” rewards a clever angle on a simple problem
• A heavy weight on “business viability” wants a deck as much as a demo
• If the rubric isn’t published, ask the organisers directly, because most will share it on request
• Winners re-read it before every major scoping decision, not just once at the start

Tip 2. Pick the hackathon type that matches your goal

Hackathons aren’t a single category of event, and repeat winners are deliberate about matching the format to what they want out of the weekend.

Within whichever type you pick, choose a problem the whole judging room can understand rather than a niche only your specialist track will appreciate, because a widely felt problem consistently beats a technically impressive but narrow one in scoring.

Tip 3. Build the team around skill gaps, not friendships

The four-backend-developer team loses to a balanced three-person team almost every time, which is why winning team composition is one of the most predictable patterns we see across events.

• One fast frontend builder
• One backend or infrastructure developer
• One strong presenter who owns the demo script
• Cross-functional teams consistently outperform all-technical teams across the events we run

If your closest friend can’t ship a demo or pitch one, you’ll need to find someone who can before registration closes.

Tip 4. Set up your dev environment before you arrive

The team coding at hour zero beats the team setting up at hour zero, and the only way to be the first kind of team is to do the setup work in the days leading up to the event.

• Boilerplate, deployment pipeline, and account access
• API keys for any sponsor tracks you might enter
• Sandbox or testnet access, all of which take longer to provision than most teams expect
• A working build pipeline you’ve already tested end to end

Without this prep, the first six hours of the event go to setup rather than building, and teams that lose those six hours rarely catch up to the ones that didn’t.

Hackathon Tips During the Build: How Winning Teams Use Their 24 to 48 Hours

Ship a stripped-down working prototype by hour six and you’ll beat the team still designing schemas at hour twelve, because the build phase rewards momentum over architecture. Four habits show up across almost every winning team’s process during this stretch.

Tip 5. Get a working skeleton up in the first 25% of the time

The skeleton has one input, one output, and the basic shape of the demo flow, and it will look bad on purpose because the goal is to have something to improve rather than something to finish. For more on choosing a buildable scope before you start, see our guide to [hackathon ideas that actually finish in 48 hours].

• 24-hour event: skeleton by hour 6
• 48-hour event: skeleton by hour 12
• Don’t mock anything core to your product, because judges can usually tell what’s mocked and they penalise it. Mock the data feed and the third-party API if you need to, but never mock the feature the judges came to see.

Tip 6. Use AI tools deliberately, not constantly

AI tools are now standard at hackathons, with most developers and professionals using them daily, so the question isn’t whether to use them but where to draw the line.

• AI for boilerplate, integration glue, and UI scaffolding
• Novel logic by hand, because judges will ask about the differentiated parts of your code and they’ll sense the gap if you can’t explain it
• Debugging AI code sometimes takes longer than writing it themselves, which means the bottleneck shifts from generation to verification, and you’ll need to budget time for both rather than treating AI output as finished work

Tip 7. Write the demo script before the meaningful code

The script is a single page with five elements:

• The problem in one sentence. State the pain in plain language, framed around a specific person rather than a category.
• The before state. Show what someone does today to solve this, including the workaround and the cost.
• The trigger. Name the exact action that starts your demo so judges know what to watch for.
• The “aha” moment. Land the single thing you want every judge to remember after the demo.
• The close. Tie the demo back to scale or impact in one line, naming who else has this problem.

If you can’t write that script before you start coding, you don’t yet know what you’re building, which is a useful signal to stop and figure it out before you commit to the wrong architecture. Show the script to a teammate, and if they can’t repeat it back to you, the script isn’t ready. Two hours spent on the script usually saves six hours of building features that won’t appear in the final demo.

Tip 8. Engage sponsor mentors during the build, not at submission

Most teams treat mentors as a help desk and only show up at the demo stage, while winners use them earlier with a specific question that signals they’ve already done the work.

• Sponsor mentors often decide post-event prizes, bounties, and follow-on grants, so getting on their radar mid-build pays off twice
• They remember the team that showed up at hour 14 with a sharp technical question, not the team that asked a generic question at hour 47
• A great build no mentor remembers is worth roughly half of a decent build with a sponsor who knows your name

Hackathon Demo Tips: How Winners Handle the Final Four Hours

The last four hours of a hackathon aren’t more building time, but a separate project with its own deliverables: a working demo, a video, a README, and a clean submission. Two tips decide most of the score in this window.

Tip 9. Lock the code four hours before submission and hardcode the demo path

New features added in the final stretch tend to break things you already shipped, which is why the lock is the single most consistent habit across teams that submit clean.

• Record the demo video twice, so you have a backup if the live demo fails
• Walk the live demo five times, deliberately looking for the points where it breaks
• Write the README so judges who don’t see your demo can still evaluate the project
• Submit at least 30 minutes early, because the buzzer is when problems show up

The demo itself needs to be defensive against the things that go wrong at every event we’ve run, including Wi-Fi dropping, APIs rate-limiting, and models timing out, so mock external services, cache responses where you can, and keep screenshots as a fallback. Judges score what they see on screen, not what almost happened behind it.

Tip 10. Pitch the problem harder than the solution

Most teams spend roughly 5% of their demo time on the problem and 95% on the solution, then are surprised when their “impact” scores come back low.

• The winning split is closer to 30% problem and 70% solution
• Use a specific person rather than a category, so instead of saying “developers waste time on X,” describe “a backend developer at a Series B SaaS company who spends two hours a week on X”
• Before the demo, walk someone outside your team through the pitch, and if they get lost, rewrite the story rather than the demo

Repeat winners submitted every time, not just when they felt good about it, because judging criteria are weighted in ways that often surprise the teams who feel like they bombed.

Hackathon Tips: The Pattern Behind 10,000+ Projects

Across 450+ hackathons that we run over 15+ years, we’ve watched what separates the teams who win once from the teams who keep coming back. The ten tips above are the patterns that show up in the second group, in our experience across every format and skill level.

The next hackathon is where you put these tips to the test. Join the AngelHack developer community to find your next event, plus quests and bounties from leading tech brands.

Hackathon Tips FAQ: How to Win a Hackathon as a Developer

What’s the single biggest factor in winning a hackathon?

Scope, more than anything else. Winners pick a problem they can finish rather than one they want to solve, because the team that ships a working demo of a smaller idea beats the team that demos a broken version of a bigger one. Almost every losing team we’ve watched scoped too big.

Does the strongest coder usually win?

No, balanced teams beat all-technical teams almost every time. A team with one fast frontend builder, one backend developer, and one strong presenter outperforms four backend engineers who can’t explain what they built, because the demo carries more weight than the codebase in most rubrics.

How important is the demo compared to the code?

The demo is usually the deciding factor at most hackathons, because judges see 30 to 100 demos in a hackathon and form opinions in the first 30 seconds of each one. Hardcode your demo path, mock external services, and rehearse the live run at least five times before submission.

What’s the most common reason strong teams lose?

Strong teams usually lose because they scope too big and run out of time, so by hour 20 they have impressive architecture and no demo. The team next to them has an uglier build that actually works on stage, and that’s the team that wins.

Should I use AI tools during a hackathon?

Yes, but deliberately rather than constantly. Use AI for boilerplate, scaffolding, and integration code while writing the differentiated logic yourself, because judges will ask about it and you’ll need to explain it. Verification of AI output now takes longer than generation for almost half of developers, so factor that into your build timeline.