Your First Hackathon: A Practical Guide for People Who Aren't Sure They Belong There

Most people who could do well at a hackathon never enter one. They imagine a room full of prodigies typing at superhuman speed and decide it's not for them. The reality is closer to a school science fair with better coffee: a lot of half-finished projects, a few that work, and judges who are mostly looking for whether you understood the problem.

Here is how to get through your first one without embarrassing yourself — and with a fair chance of placing.

Before the hackathon starts

Read the brief three times. Hackathon briefs are usually vague on purpose ("build something that improves urban mobility"). Hidden inside that vagueness are the judges' actual interests. Look for hints: which sponsor is involved, what examples they give, what the prize categories are. A "best use of location data" prize tells you exactly what one judge cares about.

Decide what you're good at and what you'll fake. If you can't code, you can still design, write, present, or research. Teams win on the combination. A team of four coders with no one who can explain the project loses to a team of two coders, a designer, and a talker.

Set up before the clock starts. Have your laptop charged, your accounts created, your development tools installed. Losing the first two hours to installation problems is the most common and most avoidable mistake.

The first two hours: pick something small

The single biggest predictor of hackathon success is scope. Ambitious ideas die at hour 30 with nothing working. Small ideas get finished and polished.

A good hackathon idea:

• Solves one specific problem for one specific person
• Can be demonstrated in under two minutes
• Has one feature that makes people say "oh, that's clever"
• Does not require data or access you don't already have

Bad: "A platform connecting farmers to buyers with dynamic pricing, logistics, and a rating system."

Good: "A WhatsApp bot where a farmer sends a photo of their produce and gets today's mandi price for it."

The second idea is a tenth of the first, and it will win against the first every time because it will actually work when the judge is watching.

Hours 2 to 36: build the demo path only

You are not building a product. You are building a demo. That means:

• Build the path the judge will see, and nothing else. If your demo is "user uploads a photo, gets a price", build that. Do not build login, settings, or a profile page.
• Hard-code what you can. If your idea needs a database of prices, a spreadsheet with 20 rows is fine. Say so honestly in the presentation; judges respect it.
• Get something ugly working early, then make it pretty. A working ugly demo at hour 12 beats a beautiful broken one at hour 46.
• Test on the actual device you'll present on. Things that work on your laptop break on the projector.

Sleep. Seriously. A team that sleeps six hours and works 42 outperforms one that works 48 straight. Tired people make bugs faster than they fix them.

Hours 36 to 46: stop building, start presenting

This is where most teams go wrong. They build until the last minute and then present something they've never rehearsed.

Stop building at hour 36. Use the remaining time to:

1. Write a two-minute story. Who has the problem? What happens now? What does your demo do instead? What would it become with more time? That's four sentences. Learn them.
2. Record a backup video of your demo working. Wi-Fi fails. APIs go down. Laptops die. A 60-second screen recording saves you.
3. Rehearse out loud, with a timer, at least three times. You will be shocked how long two minutes isn't.
4. Prepare for three questions. "How is this different from X?" "How would you make money?" "What was hardest?" Have honest answers.

Presenting

• Lead with the problem, not the technology. Nobody cares which framework you used.
• Show the demo live if it works, video if it doesn't. Don't apologise either way.
• If something breaks, say "here's what it does when it works" and move to the video. Judges have seen a thousand demos break. They're judging how you handle it.
• End with what you'd do next. It shows you understand the gap between demo and product.

After

Win or lose, do three things:

• Push your code somewhere public and write a short README. It's now part of your portfolio.
• Connect with the people you met. Hackathon teammates become co-founders and colleagues more often than you'd expect.
• Write down what you'd do differently. Then enter another one.

On Sanora One, hackathon entries are judged with a mix of AI scoring and human panels, and every entrant can see their rubric scores afterwards. That feedback is the most valuable thing you'll take away from your first attempt — more than the prize, and certainly more than the T-shirt.