In autumn 2018, our team took part in a sharing economy hackathon organised by Mercari, Inc. We played kicker, threw some darts, wrote code, and — as it turned out — pitched the idea the judges liked most. First place.
It was a good experience, and not just because of the result. Hackathons are worth attending even if you don't place. But since we won, we figured it's worth sharing what helped.
What a hackathon actually is
A hackathon is a timed competition — usually 24 to 48 hours — where teams of developers, designers, and product people build something from scratch and present it to a panel. In theory. In practice, almost every team comes in with an idea already formed. Some arrive with a working prototype. A small number show up with a startup they built months earlier and use the event mostly for pitching. Many hackathons allow some prior work, provided you're transparent about it with the jury.
The more important point: hackathons are not about writing pristine code. They're about ideas, prototyping, and communication. A clean, functional demo will beat a technically complex build that nobody understands. If you're not a specialist in a given domain, that's not a disadvantage — it might actually help you see the problem differently.
How to prepare
The biggest mistake teams make is treating preparation as optional. You will not have time to figure things out on the day.
Before you arrive:
Develop two or three ideas, not one. Mentors may reject your first suggestion, or you might discover another team has already built it. Have a backup that you're equally comfortable with.
Know your tools before you need them. If your idea depends on a framework or API you've never used, spend an evening with it beforehand. A hackathon is not the place to work through a tutorial.
Install everything and confirm it works. Dependencies that fail to install at 2am are a real problem.
Bring business cards. Hackathons draw interesting people, and the conversations you have between sessions are often as valuable as the event itself.
The idea
Your idea needs to be explainable in two or three sentences. If it takes longer than that to describe, either it's too complicated for a hackathon format, or you haven't understood it clearly enough yourself yet. Both are problems worth solving before you walk in.
Buzzwords alone won't win you anything. That said, if your project uses AI or another prominent technology in a way that genuinely makes sense, that's a real advantage — judges respond to familiarity when it's backed by substance.
The pitch
The pitch matters more than the code. This is the part most technical teams underestimate, and it's usually why they lose.
Explain the problem clearly, explain why it's worth solving, and show how your solution addresses it. A live demo — even a limited one — is significantly more convincing than slides. Know exactly how long you have and rehearse to that time. Every hackathon has a hard cutoff. Every hackathon also has at least one team that runs out of time mid-sentence because they were still fixing bugs ten minutes before the presentation. Don't be that team.
Reserve proper time for pitch preparation. It's not a nice-to-have.
It's worth doing
Even if you don't win, hackathons are good. The time pressure is real, the problems are concrete, and the format forces you to prioritise in ways that ordinary project work doesn't. You meet people, you practise pitching, and you come away with something you actually built.
Go in with a prepared idea, a working prototype if you can manage it, and a pitch you've rehearsed. The rest tends to follow.
