How to win an online hackathon (and have a good time)

A guide for what to expect and how to prepare for winning an online hackathon.

20 min readJul 23, 2021

This article focuses on longer-term (2–4 weeks) primarily technical hackathons.

I have participated in 5 hackathons, most of which have been online. In these multiple hacks, I’ve learnt a lot about organising a group of decentralised hackers to build a good product, and have a good time doing it. Online hackathons present a very unique set of problems and require a relatively structured process. I have worked out this process over many hackathons but really nailed it down in my last two hackathons: EthGlobal Scaling & EthGlobal HackMoney.

In this article, I will share tips, tricks and the processes I’ve developed to get the most out of an online hackathon. An important thing to realise though is that hackathons take work. You don’t win by accident. It takes planning and consistent hard work.

If you don’t put the time in, you will get nothing out.

Below is a quick overview of everything covered by this article.

· Not all hackathons are created equal
∘ Side note on important things to know before it starts
· Define “Winning”
· Building a team
∘ Choosing team members
∘ Side note about solo hacking…
· Aligning Interests
∘ Communication Platform
∘ Planning Doc
∘ Side note on brainstorming
· Building the thing
∘ Side note on pivoting
∘ Side note on problematic teammates
· Getting ready for judging
· Making a Demo video
∘ For your slides:
∘ For the demo:
· The importance of a little showmanship
· On air: Handling live judging
· Next steps
∘ Side note on splitting the prize money
· Closing thoughts

Not all hackathons are created equal

Before we can get into how to absolutely crush a hackathon, we need to look at the hackathon itself. Not all hackathons are created equal, and here are just a few things to consider when choosing to participate in an online hack:

Have the organisers run an online hackathon before?
Running and organising an online hackathon is an entire beast in itself. If this is the first online hackathon the organisation has run, expect a bumpy ride.

How do the organisers help you with team formation?
Organisers make or break a hackathon. If you plan on hacking with a team that you do not already have (i.e making a new team) and the organisers have not made some facilities for networking around team building… you will really struggle.

How many hackers are there going to be?
Ensure there will be enough hackers in the hackathon to build a team from. Depending on what winning means to you will determine what your minimum should be, but I would not participate in a hackathon that has less than 150 hackers signed up.

Who will own the IP created?
Nested in the Ts&Cs of some hackathons is the condition that what you submit to the hack is not your IP. If you want to make a real thing that you take forward this is a non-starter.

How much prize money is there?
As with everything, depending on what winning means to you this ranges from insignificant to very important.

Side note on important things to know before it starts

Before the hackathon gets close to starting you should gather the following information:

When is the submission due? Make very sure you understand when you can start and have to stop coding.
How do you need to submit it? Is there a form, do they have a preferred format?
How does judging work? Is there a video submission with judge feedback? Or do the judges look over submissions privately?
What is the hackathon focused on? This is really important in ensuring your project is actually relevant. If it is a great new wallet application but the focus is on data it really doesn't matter how fantastic your product is it will not win anything and you might not even be able to submit it.
What are the sponsors looking for? This is more important if you want to get a lot of prize money, but understanding what the sponsors are looking for can make it easier to brainstorm and ensure your idea is relevant. Often sponsors will have their own lists for hack ideas.
What are the rules around submissions? Understanding the rules and guidelines before you start will save you a lot of stress and uncertainty. I know these docs can be long, but read them!

Hackathons are a great way to get exposure, both as an individual but also for market validation of an idea. Most hackathons will require a completely fresh start of the project during the hack, so make it clear you didn’t do work before. The easiest way to do this is a new repository with a clean start after the hack kick-off. Seriously, you don’t want to put 3 weeks of effort in only to get kicked because you worked on it before the start.

Define “Winning”

Before you can win a hackathon, you need to define what winning means to you. If you are new to a space winning might be gaining understanding and starting a network. Below are some of the most common ways to “win” hackathons:

Learning. A new tech stack, a new integration, or even a completely new field. Hackathons are a great way to get your hands dirty. Hackathons can also be a great CV/LinkedIn bolster.
Making a (new) product. Hackathons are a great way to get relevant market feedback about a new product, as well as generally testing the waters for grant and funding opportunities.
Launching a new version of a product. Hackathons can be a great launchpad for existing projects, complete with just enough “press” to make a splash. Of course, you will need to put in that much more effort to fully capitalise on the momentum of the hackathon.
Hiring & team building. Hackathons are a surprisingly great way to grow/start a team. You get to work with them in stressful conditions and see how they work and what they are capable of. Plus, you don’t have to pay them, because it's a hackathon they were going to do anyway! Make sure, however, that your intentions are clear with potential team members. There are lots of people who are hacking that are happy at their current job. Being clear prevents you from wasting everyone’s time. Check with your hackathon organiser before you start advertising your team as a “potential job” source, as most have rules & guidelines around this.
Winning (lots of) prizes. This is harder to optimise for, especially if this is your first hack. I’d recommend greenies to see what has won previous hackathons for inspiration. When optimising for lots of prize money it can be tempting to integrate with every possible sponsor, this is a rookie mistake. First and foremost you need to have a good product. Focus on building a talented team, then look through the sponsors as a group and figure out a cool product that integrates with 2–5 of the “big” sponsors, and no more than 5 smaller sponsors. Using more sponsors than that will almost inevitably reduce the quality of your product significantly.

Building a team

Building a good team is the most important part of kicking ass at a hackathon (closely followed by the product). For technical hackathons, the most important thing to optimise for is shared stack and good developers. If you have 4/5 talented developers who all use different languages you are in trouble.

I normally recommend rallying around JS/TS because it cuts from back to front really well. However, you can really choose any language but keep in mind if you want to build a frontend, backend and or middleware how your chosen language will affect framework choices and potentially massively limit your candidate pool.

Something that might slip your mind is to make sure someone has even a little design & UX experience. You need your UI to be not ugly. Doesn’t need to be gorgeous, but it needs to be presentable. For projects continuing after you want to strive for gorgeous.

Choosing team members

I recommend having at least one meeting with potential teammates before accepting them into your team. Below are important points to cover in the meeting (usually won't need more than 30 minutes to cover everything):

What their stack is? What languages do they know, and how comfortable are they in those various languages? Are they more comfortable on the backend or UI? Do they want to try learning something new during the hack?
Why they are hacking? If you are hiring, this is extra important, as you want to understand their availability and if they are actively (or passively) looking for a new job.
What time zone they are in? Across all your hackers the least you can get away with is a minimum of 2/3 hours of overlapping availability, but the more the better.
How much time do they plan to commit to the hack every week? This is so important we will cover it again in aligning, but it will affect the availability overlap significantly.
When they are going to be working on the project? If they are committing 20 hours, when are they going to do them? Over the weekend, before work, or well into the evening? This is important to understand as you need to match up not only timezones but availability within those timezones.
If they have any ideas for the hack/what do they think of your idea for the hack? If you have an idea, do they like it? Does it excite them? If you don’t have an idea, what ideas do they have? What areas are they most excited to work in?

If you want to potentially hire hackers after the hack, I’d recommend having more than one call as you cut down your candidates.

Be warned though, building your team is a fine balance between curating until you have only the best and losing potential candidates to other teams. You need to move fast and decisively. No matter how well you screen your potential hackers, you will get slackers, dropouts and low-quality developers. If you have a team of 5, with 2 devs (excluding yourself) who are putting in the time and effort that they originally committed to you have done extremely well.

Side note about solo hacking…

I have done solo hacks before (where it is just you hacking) and it is HARD. You need to build the entire thing, and depending on what you want to build that is a tall order. Additionally, you lose the support of a team and the ability to get a second pair of eyes on a problem.

If you are going to solo hack you need to plan the hack well in advance. Do some actual sprint planning. Plan it out enough that you will be able to see very quickly if you are falling behind (you can only fall behind if you’ve planned ahead).

You should also take advantage of all the support channels offered by sponsors. Are they having 1:1 sessions? Workshops? You should be there with your questions ready, they are often very approachable outside of calls as well. Don’t dismiss these resources.

Aligning Interests

When you’ve found your team members it is time to align everyone. This can safely be done before the start of the hack, or right at the beginning. Do not skip this step if you are hacking with other people.

You are going to want to set up the following things:

Communication Platform

You need somewhere for your team to communicate. I recommend setting up a discord server (which is free) with the following channels:

General chat. Where most of your coms will happen.
A channel per section. i.e design, UI, backend, data management etc
A process channel. More on this later.
A prize channel. Just for listing the prizes, you are applying for, and for after the hack to keep track of which sponsors need to pay you.
It can also be nice to add a channel per big sponsor you are applying for, just to keep track of the discussions as well as how the integration is going, questions etc.

Discord server set up from two of my hackathons.

You can also get away with some kind of group chat like Telegram/WhatsApp/Signal but I recommend discord so that all your conversations aren't happening on top of each other, as things will get lost (especially if there are timezone differences).

Planning Doc

The most important thing about this document is getting your team on the same page (literally). The main sections you want to have:

Project Idea. What are you building? If you are brainstorming as a team this will be the ideation section.
Team Commitments. Who everyone is, their timezone, weekly hour commitment as well as when those hours are going to be spent (i.e 20 hours a week throughout the week, after work 5 PM — 11 PM).
What needs to happen. The next steps you need to take. This could look like this: Come up with project name, create the repo, or could be more detailed like design UI, figure out data architecture etc.
Sprints. This is doubly important for solo hacks, but still vital for team hacks. I recommend 1-week sprints, possibly shorter depending on how much time your hack is for. Define what should get done by when. If your team is still brainstorming for an idea focus on that then come back to this.

Side note on brainstorming

If your team is brainstorming, don’t be afraid to reach out to the various sponsors or hack organisers to see if your idea is good/relevant. A well organised online hack will have a session for idea feedback. You want to be pretty certain your idea fits the hackathon before you put the mountain of effort in that is needed.

Building the thing

Great! The hack has just started, your team is organised with the planning doc, and you have settled on the idea. Now what?

Your sprint doc now needs to be fleshed out into GitHub/GitLab issues. I recommend taking the planning of your hack pretty seriously, do some project management. The difference planning makes is the difference between being a finalist with a lot of prizes and having half your team quit before the submission is even due. Don’t neglect it.

Work as a team. Get everyone to take an area of responsibility. Make sure everyone is happy and feels the deadlines for tasks assigned to them are reasonable. You are leading your team, but it is not a dictatorship.

Check-in regularly with the entire team. You want to be talking at least twice a week. Remember that as the leader of the team, your team is taking examples from you. So if you are not excited about the project and working hard, they will not be either.

Side note on pivoting

Sometimes during the hack, you realise your original idea is not feasible, or technically too complicated for the hack, etc. and you need to pivot. Some tips that will make pivoting easier:

Be decisive. If the idea is not working, say something. have a team meeting, but be quick about it. If you spend a lot of time back and forth or doubting ideas it may derail the whole hack.
Include everyone. The whole team should agree that it is not working, and work together to figure out where to go from here. Involve your team in all the big decisions.
Can you strip it out? If a certain element of your project is the issue, how can you reduce the amount of work that will need to be re-done? Can you simply take the problem part out and put in something different? The less you have to start from scratch the better.
Be realistic. Realise that a decent amount of time is already lost. If you completely pivot be realistic in how much you will be able to get done before the deadline.

It’s never too late to pivot till it is too late to pivot. You can always submit something that doesn’t work, and it is better to submit something broken than nothing at all.

Side note on problematic teammates

Sometimes, despite all your screening, you will have a deadweight team member. Someone who is not contributing, or is difficult to communicate with or an all-around ass. Depending on how deep you are in the hack, and how problematic, you have a few options.

Talk to them. There might be something going on in their personal life that is taking priority (I’ve had team members starting new jobs, moving houses, getting married, you know, life stuff). It might be something that will resolve quickly, but you will never know unless you ask. The result of this conversation might be updating the planning doc with their new availability, them leaving the team, or moving issues to other hackers.
Talk to your team. I mean individually, don’t have one big group call to talk 💩 about the problem member. See if anyone else has noticed the problem, or if they have an issue with it. This will let you know how much of an impact kicking them would have. Be very slow with this conversation, “what do you think of Bob’s contribution? Have you enjoyed working with them so far?” Try not to “lead” them to your conclusion.
Final talk. Talking to them didn’t have the desired behaviour change? Let them know that the team needs more effort from them. Remind them what they originally committed to, what you updated it to etc. Don’t out other team members here with “oh well Alice says that you aren't working enough/are difficult to work with”. You will need to decide here if you are going to kick them (I don’t recommend kicking people. It is rarely worth it), or if you are going to ask them to take less prize money as a result of their lacking contribution. Let them know the stakes.
Kick them out your team. This is easier earlier in the hack but be warned it is never actually anywhere near easy. It is also incredibly time-consuming (much more than you’d expect). It creates drama and can destabilise your team dynamics. They might even file a complaint with the organisers, so be very sure it is worth it.

In summary, as the team leader, you need to be on top of your communication game. It is much easier to set standards earlier than it is to try to force them later. The earlier you communicate with your team members about problematic behaviour, code, practices etc, the better. Don’t let gossip or talking behind peoples backs start either. You need to be the adult in the room. If a team member is so bad you or other teammates feel the need to talk 💩 behind their back, you need to deal with that right there and then. Don’t let it fester because it will blow up.

Getting ready for judging

So you’re finishing up your hacking (or maybe only now realising how behind schedule you are and crunching) and the realisation dawns on you: you need to get ready to be judged.

Depending on how much stuff you have left to do in the time you have, this will be more or less of a priority. But some nice things to do:

Get all your repo docs up. How to set up the code locally, get it running, setting up the env whole nine yards. Make sure your code is up to scratch with its style guide.
Make sure your website has an SSL certificate.
Make sure your website has a landing page that (even if briefly) explains what your app does.
If you are taking it forward, have a Twitter account step up, and a telegram channel or discord server. Some way for people to contact the project after the fact. You are also going to want to add this information everywhere you can, your website, demo etc.

Making a Demo video

Now you need to start on the video demo. It is important to follow any guidelines that the hack organisers layout for you as they might have a specific format in mind. There are a few key things your demo video should show irrespective, so let's get into it!

The winning strategy with demo videos is half of the allocated time in the slide show (maxing out at around 2 minutes) and half the product demo. The product demo should be the priority/main focus, at the end of the day, it is what people are watching for.

When I say I’ve got this down to a science, I am not joking, so without further ado, the science of a winning demo video:

Have a script for the demo video. This will make it 1000x easier to ensure you cover everything you need to say, and also make recording + editing much easier. Try to get a full run-through, remember that if you make it into the finals you will most likely need to do the same demo live, and without the magic of editing.

For your slides:

Cover slide. Project name + Hackathon name. Nice and clean, ideally with both logos. All you need to say here is something along the lines of “we are team product, and this is our submission to hackathon”.
Team slide. Who built this? It’s nice to put name + country + what their responsibility was (like what part of the project they built, i.e built front end). If everyone is comfortable, profile photos and Twitter accounts are a nice touch. If you are hacking anon then a meme for your photo works too.
The pitch. A one/two liner for your product. This should have an impact, and possibly be a little dramatic. i.e The ultimate wallet management tool. You pretty much just want to say what is on the slide for this one, it will make it stick in viewers heads better.
(optional) The problem. The “why” of your product. If you are building a product that you want to turn into a real thing, you are going to want to spend a little more time going over why your product is a good idea/so much better than what is out there.
What you built. The “what” of your product. You are also going to want to mention where the product is like the website URL, what network your product is deployed on etc. If you plan on taking the product forward I recommend putting the URL on every slide somewhere (headers/footers work nicely).
Specifics. This is the “how” of your product. If you built anything that was particularly novel/complex or cool this is where it goes. Also good to mention here the sponsors you integrated. Make sure here that the visuals are engaging, split topics into their own slides with a nice diagram or screenshot.
The Demo! Before this point, you might want to have one or two screenshots of the product/UI just to get the judges excited. I’ve found the best way to record this is to record a screen share on Zoom.

For the demo:

Start as a “new user” on the app. Going through the signup flow. If in the editing of the video realise you are running out of time it is ok to make this literally a 3-second speed run.
Go through the “main” user flow. What are most people going to use your product for? Do that. Explain what is happening while you are doing it. i.e “When we click here *click* the app is generating your data request.”
If things aren't critical to the functionality and take time (like transactions mining) you can cut those out when editing, just make sure that it is clear that it happened.

8. (optional) Next Steps. If you are building a product that you want to turn into a real thing, you need to show that you have a plan. Have on the slide contact info for anyone interested in funding or getting involved. Explain what your plan is for the next steps, i.e we plan on raising funding to launch this!

If any of this doesn’t make sense to you, check out my demo video for the last hack I did here. It is a nice example that mostly follows this format.

The importance of a little showmanship

One of the worst things you can do for your demo is talk in a flat monotone voice, with no intonation or personality. No matter how amazing, technically accomplished or world-changing your app is, people will get bored and not pay attention.

I like to throw in one or two (max three) tasteful relatively mainstream custom memes to keep the visuals fresh and interesting. Make sure, even though you are reading a script, to put excitement in your voice. Practice the script a couple of times before recording. You need to sound interested, and interesting!

On air: Handling live judging

Firstly stay calm. Secondly, we are going to use that beautiful slide show we made for the recording, as well as the script for the entire presentation. You might have been given more time for this demo than the recorded one. If the extra time is less than 2 minutes, don’t change anything.

Now for the actual production part of the demo here are some tips and tricks to make it go down smoother:

Pray to the demo gods. I might be a bit superstitious on this one, you’ll just have to take my word.
Be clean. Make sure your bookmark bar is hidden, notifications are muted/silenced. If you need to show your desktop, make sure your background is decent. You should only have the slide show and the website open in your tabs.
Have backups! Say you want to demo that a transaction happens by making the transaction and then showing it on etherscan. Have that transaction from a previous run through open on etherscan just in case it takes too long to mine, you don’t need to panic because you have one ready!
If something goes wrong, keep to the script! Try (as best you can) from being like “oh… it’s not supposed to do that”. Keep the panic inside and carry on, even if it means talking about something that is not happening visually.
Have a team member ready as a backup presenter. There are plenty of things that could happen that would require a team member to have your back (like your interest connection deciding to get unstable). The easiest way to do this is to have them ready with your recorded demo so that if you peg they can just share their screen and play the demo from where you left off.
Be prepared for things to be slow. If there is something on your product that takes a while to happen, have the before and after state ready in two tabs. It is easier to say “I’ve pre-loaded this blah blah” than it is to talk off the cuff to stall for a minute (or demo forbid multiple minutes) while something happens in the background.

Next steps

You want to take advantage of the little press you will get from the hack, as well as the momentum you have built. Be actively updating your socials with the progress of the app throughout the hackathon. Reach out to any sponsors (whether or not you won something from them) about grants, incubators and funding opportunities.

After the hack, if you’ve made a bit of a splash you might even get cold emails/reach out from VC funds. Be reasonably sceptical about this. If you do want to take on VC funding you need to be very intentional about it and very sure that this VC can give you more support than just funding (i.e network, influence, mentorship etc). If this is your first startup be doubly sceptical.

Now is a good time to apply to some relevant incubators, (especially for first-timers) as they will give you (hopefully) a lot of structure, support and guidance.

Side note on splitting the prize money

Splitting prize money can be contentious, especially if some team members did not pull their weight. I really recommend an even slipt between everyone 98% of the time. However, if someone was not pulling their weight, and you had the leadership kahunas to talk to them when it became a problem, you might be able to get them to agree to take less. Just know that this can get ugly very fast, and you’d better be willing to die on this hill (and possibly lose all the rapport you’ve built within your team).

Closing thoughts

Hackathons are a great way to learn and grow as a developer, as well as being incredible launch pads for products. However, you will only get out what you put in.

Remember throughout the hack that it is about having fun, and even if you don’t win anything you’ve probably learnt a lot, met new people and grown as a developer and team player.