Last edited: 12-Dec-2024
In the last four years, I've taken part in 10 hackathons across three different countries. Of these, I've won 6 and placed in the top three teams in the remainder1. At the peak, I won $10,000 in a weekend.
This blog aims to be a general set of techniques for each stage – team-building, ideation, coding, and presentation – to massively increase your chances at winning.
This, of course, assumes your goal is winning. Many people go to hackathons to build their network, interact with sponsor companies, learn about new technologies, or do karaoke. These are awesome things to do. They are not the same as winning.
1. Team-Building
I've done hackathons with a team of friends, and I've also done hackathons with total strangers. If rules allow, I recommend working with friends but, either way, there are two important qualities of a winning hackathon team:
Everyone is a "do-er".
You want people who will "do stuff". This means being focused on the project, being self-sufficient enough to figure out how they can contribute, and executing quickly on tasks. There is a surprising heuristic you can use to find people who “do stuff”. People who like discussing ideas are more likely to do stuff than people who like discussing credentials or past experiences.
At a recent hackathon, I arrived late without have a team or idea. I found most people in the lounge area at the front discussing their universities, work experiences, and skillsets. There were a few people gathered around whiteboards at the back of the room sketching out ideas. Guess who won the hackathon?
Smaller is better.
I like teams of 2-3 people. You will find that, even in larger teams, most of the work is done by 2-3 people. The goal with team size is to make sure everyone has enough work to do, no one is treading on each other's toes, and everyone gets to learn something new. Small teams are best to achieve all of these goals.
2. Ideation
This is the most important part. A good idea wins a hackathon. A good team, good code, and good presentation all contribute, but the idea is the thing that wins.
A good hackathon idea has 3 qualities. It must be: (1) novel, (2) elegant, and (3) inspiring.
Novel
You can find novel ideas by deviating away from the hackathon's "theme". Perhaps in a productivity-themed hackathon, you're building an app for dyslexic people. Maybe in a crypto-themed hackathon, you're building a hardware project.
One thing I like to do is to take cool technical demos I have come across online and figure out how they can be applied to a new use-case. For example, in 2020 I saw Google Research released a [real-time face detection](https://storage.googleapis.com/tfjs-models/demos/facemesh/index.html) SDK. I used this to detect the distance between a user’s face and their phone, creating a tool which tells you when you’ve been holding your phone too close to your face for too long. In 2023, I read about the way that the United Nations [guarantees refugee anonymity](https://unstats.un.org/bigdata/task-teams/privacy/guide) when releasing open immigration datasets. I used the same techniques to implement a two-way trustless data transfer protocol in a cryptography-themed hackathon.
Elegant
This is a matter of taste and depends on the "culture" of the hackathon. Ask yourself: who's judging this, what are their criteria, and what kind of projects will excite them? For some hackathons, elegance means a seamless user interface and fluid animations, while for others, it means a new algorithm to speed up previously inefficient processes.
In one hackathon I attended, another team won by implementing a new way to log in to websites by tapping a specific rhythm on your spacebar. Although clearly quite impractical (anyone can hear your password in a public place), the project won because it had a beautiful interface where users could see waveforms appear as they tapped out their password. In a 30 second pitch, aesthetics often beat practicality.
Inspiring
There has to be an answer to "so what?". For any weekend project, it's hard to project how any of it impacts the future but, to stick in people's minds, you must present a grand vision.
For example, at a deeptech-themed hackathon in London, my team and I built a tool which detected an object across multiple camera feeds and mapped it onto a single floorplan. It was **novel** because, with some clever image preprocessing, we were able to use large multimodal transformers (e.g. GPT-4o) to do the heavy lifting. Typically, this kind of task requires complex and compute-intensive localization algorithms. It was **elegant** because our demo video showed the object move on the floorplan as it moved in the camera feed (oddly satisfying!). It was **inspiring** because we talked about how these tools can be used to crowdsource intelligence in the context of disasters, urban crime, or battlefield awareness. Currently, natural disaster intelligence relies on active civilian reporting. If CCTV and civilian recordings can be synchronised to quickly determine the size and location of dangers (e.g. fires), we can mitigate the damages caused.
3. Execution
Split up work so it's extremely clear who's doing what. My main tip here is to use languages you are familiar with and frameworks that allow you to get off the mark as soon as possible. If you don't know how to do something, ask around! You might be pointed to a technology or framework that you're unfamiliar with. In that case, read the quickstart guides, watch YouTube videos, read documentation, and ask for help until you know how to get going. Also, resist the urge to write perfect code. This is a weekend project, not the next Google.
Here are my recommended frameworks for software projects but, really, use what suits you:
[UPDATE: For creating web apps, I now recommend using the T3 stack. Start with this and aggressively cut out anything you don’t need (e.g. database)]
Frontend
I use Typescript. Generally, rip off from component libraries or template websites wherever you can. AI-powered coding makes frontend 2x faster so be ambitious with your designs.
- Web: I like [Next.js](https://nextjs.org/) - it's React but faster. I also use [shadcn/ui](https://ui.shadcn.com/) component library.
- Mobile: I think [Expo](https://expo.dev/) is excellent. It has React-like syntax and let's you build on Android / iOS very quickly.
Backend
I like Python so I use [Flask](https://flask.palletsprojects.com/). I know some folks prefer [Express.js](https://expressjs.com/).
Database
90% of the time, you don't actually need a DB. This might come as a surprise but, most of the time, I've made do with a .txt or .csv file sitting on my backend server. If it's really needed, I use [SQLite](https://docs.python.org/3/library/sqlite3.html).
Hosting
Again, most hackathon projects can be run locally. If I need to host, I use [Vercel](https://vercel.com/home) for frontend and [Render](https://render.com/) for backend.
4. Presentation
This is the most underrated part of a hackathon: telling a great story. You often have very little time and are competing with dozens of other teams for mindshare.
1. Start with a strong hook, laying out the big problem you're solving (inspiration).
2. Go into technical details focusing on the challenges you overcame (novelty).
3. Demo your project, which should speak for itself (elegance).
4. Finally, close on an extremely memorable point about the future potential of the project.
Conclusion
So there are the big secrets. Now you know them, they will seem super obvious:
- Bring together a small team of do-ers
- Find a novel, elegant, and inspiring idea. Spend as much time as you need to get to an idea that's good enough.
- Stick to familiar technologies but don't be afraid to ask for help when exploring new tech
- Tell a compelling story. If some people in your team are better at pitching than others, let them pitch.
I will end by noting that hackathons are genuinely a good opportunity to do the other things I mentioned at the beginning: networking, socialising, and having fun. Some of my best memories are midnight antics with random strangers at hackathons. However, there is great thrill in buckling down and putting everything into winning something difficult.
The probability of this happening by random chance, based on the number of teams and number of winners in each hackathon, is <1e-6 or less than one in a million.