Intro

There was a period in my life when I used to regularly find and attend hackathons – and I’ve always wanted to share my learnings – so this article is going to be a list of actionable advice to get the absolute most out of your next hackathon.

I’ve written this article in two main parts – which you may skim or skip as you like:

• Rationale – high-level overview
  • What is a hackathon and why would you go?
  • How does a hackathon run and what can you expect?
    • Before
    • During
    • After
• Advice – deep dive and actionable
  • Time
  • Idea
  • Team
  • Setup
  • Planning
  • Execution
  • Demo
  • General
  • Afterwards

I hope this article inspires you to go, or if you’ve already been, share your tips and tricks in the comments, or perhaps share this article to inspire others to go and catch the bug!

Rationale

What is a hackathon and why would you go?

A hackathon is generally a physical event, spread over one or two days, where groups of interested parties form teams and collaborate to build a product or service that didn’t exist in the world before.

Usually events have an overarching theme or problem space for attendees to unite behind, and sometimes a company or organisation will host or sponsor the hackathon to generate interest or momentum in a particular area or for a product or service.

Sometimes folks will form teams in advance, or they may form teams on the day with people they’ve never met before, and usually at least half of the attendees will be technical and capable of realising the final project.

Folks may arrive with a set idea of what they want to build, or teams might decide on the day what to build. Some hackathons bring together non-technical people who will pitch ideas and bring the domain knowledge to generate and drive the individual projects.

There are also a wide variety of motivating factors that encourage folks to attend. Perhaps they have an existing interest in the problem space, or want to sharpen up their skills. Maybe they’re bringing an idea to see if it has legs, or find co-founders for a future endeavour. Or maybe they’ve caught the hackathon bug and and just love the experience!

How does a hackathon run and what can you expect?

Generally a hackathon has a few distinct phases, depending on the overall format or duration.

Before the event

1. Theme
   A hackathon will generally advertise the theme or domain in advance, so attendees know if it will be of interest to them. They may also share information about prizes, constraints, or other facts pertinent to the endeavour.
2. Team
   If teams are allowed to be formed in advance, this is when you gather your compadres, and come up with ideas. Otherwise, you turn up on the day and just get involved!
3. Preparation
   Your single biggest enemy on the day is time. You need to make as few unnecessary decisions, or get caught up in as few needless tasks as possible. Your aim on the day is execution so the more you can prepare or practice in advance, the better.

During the event

1. Registration
   A good hackathon will start at a decent hour, so plan your route and aim to get there on time and get settled. You’ll have a lot to do on the day, so don’t mess this bit up!
2. Pitching
   Some events begin with folks pitching ideas. If you’re pitching, make sure you can communicate your idea succinctly (aim for 30", verbal only) and give folks some idea of the aim and impact, and what skills you need. If you’re watching, keep notes of the people or projects you like, as you will need to find them after.
3. Team formation
   If teams are not already formed, this is the bit where everyone attempts to meet everyone in their shortlist, and build teams. This can be pretty crazy; be prepared to wait or come back, or not get into a team you want. Expect to wrap up in around an hour.
4. Planning
   Once teams are formed, you’ll need to align on an achievable idea and plan the work. You should aim to be up and running as soon as possible! Make sure everyone has a role and knows what they need to do. Ideally have a project leader, and set up some basic project management.
5. Execution
   This is the bit you need to maximise. Get started. Don’t waste time. Skip the lazy lunch. If you’re stuck, say. The time will fly by so much quicker than you expect. Also, remember, you need to present something at the end; no one wants to see a broken app or a powerpoint of what it would have looked like (if you’ve done that, you missed the point of the event).
6. Sustenance
   Ideally, food and drink will be laid on. In a shorter hackathon you want to eat whilst you work, but in a longer hackathon you can take the evening meal to get to know your team or plan the next day. Remember your brain needs some down-time and you’re here for the experience – but time is of the essence, so find the right balance.
7. Sleep
   If your hackathon runs over two days, you’ll need to factor in some shut-eye! Sleeping at the venue may or may not be practicable, and working through the night – whilst temping – may crucify you for the remainder of the time. Definitely get some sleep. Your team will thank you for it.
8. Demo
   The culmination of everyone’s hard work! Teams take turns in presenting their projects. Make sure you can present your idea succinctly and demonstrate value or potential. Make sure someone has practiced the presentation. You will be scored or judged.
9. Prizes
   Once the scores have been tallied, teams will be called up to receive their prizes. Hopefully you’ll be buzzing at this point, but you may be feeling wiped out or possibly sleep-deprived! Celebrate the wins, put any regrets behind you, and reflect on any disasters or losses. You will have gained much even if you leave without a prize!

After the event

The end of the hackathon is often not the end of the story.

• Maybe you want to polish your project, or release it to the world
• Maybe you want to build on the foundations of the core idea and keep working with those people
• Maybe you want to leave with your learnings, and do better at the next hackathon

But hopefully you’ll have made some new friends, learned a little more about yourself, and feel like you’ve done something exciting that you hadn’t done before.

Advice

So you read the above and think you want to hit a hackathon. Great!

This section deep-dives what you’ll need to know to nail the execution. Know that the time going to fly by, teams may be extremely competitive, and there’s no feeling more frustrating than reaching the end of the event and feeling like you missed the target.

Time

It is almost impossible to overstate how little time there is at a hackathon to build something, and as humans how terrible we are at both estimating how long things take, and being cognisant of how long a task we are doing has taken.

If your hackathon is a single day, you may only have around 5 hours of working time:

• 9am - 11am: registration, intros, team formation, planning
• 11am - 4pm: actual work time
• 4pm - 5pm: prepare demo
• 5pm - 6pm: demos

How much work do you realistically think you can get done in 5 hours?

If you have a weekend hackathon, you’ll get around 17 hours:

• Saturday

  • 9am - 11am: registration, intros, team formation
  • 11am - 11pm: actual work time

• Sunday:

  • 9am - 2pm: actual work time
  • 2pm - 4pm: prepare demo
  • 4pm - 5pm: demos

And if you start on the Friday night, it may stretch to around 22 hours:

• Friday:

  • 7pm - 9pm: registration, intros, team formation
  • 9pm - 11pm: planning (or socialising! But take it easy; you don’t want a hangover)

• Saturday

  • 9am - 11pm: actual work time

• Sunday:

  • 9am - 2pm: actual work time
  • 2pm - 4pm: prepare demo
  • 4pm - 5pm: demos

If you have the luxury of two days, you should look at the last day as a bonus day; it will be under half the length (5 hours) of the previous day (10-12 hours).

Make sure to break the back of the work by the end of the first day, and ideally work in enough time to be able to present your work so the audience understands it and would be likely to vote for it.

Do NOT run out of time. Constantly be thinking how to deliver iteratively so you have something to present.

Idea

For a team to be in with a chance of winning, you need an idea that:

• solves an interesting problem or generates an interesting outcome
• people at the event would be motivated to work on
• is achievable in the given time with a given team size

The idea has to be interesting, or else no one will care when you present.

People have to be motivated to work on it, or else you won’t be able to recruit and leverage the skills of a larger team.

Your idea – or a subset of your idea – has to be achievable in the given time and with the given team, or else you will spend too much time theorising, not enough time executing, and will have nothing to present at the end.

Depending on how much time you have at the event you’re really looking to build a proof-of-concept, conduct a feasibility exercise, or perhaps launch a plugin for a framework or ecosystem. Or perhaps your hack is not a product but a service, or a marketing campaign, and you want to leverage vitality and network effects, and the hackathon is the first step in bringing together the right people and placing a small bet on a seed that will be planted at the event but grow roots after.

Be prepared to modify, re-think or reframe your idea at any point to make sure you can deliver on the essence of it.

Team

Your team can absolutely make or break your hackathon, and there are various things to think about.

Team size is one of the most crucial choices to make:

• a two person team may work great together, but you’ll lack the firepower of a larger team, and may not get enough work done in the time to compete with larger teams (but, don’t let that stop you!)
• a four to six person team is probably the sweet spot; any more and people may not have something to do or it becomes too difficult to meaningfully split and coordinate the work

Here’s some examples of team splits:

• 1 person: 1 full-stack or 1 designer / marketer (perhaps they are creating a campaign)
• 2 people: 1 frontend / designer, 1 back end
• 3 people: 1 frontend, 1 backend, 1 designer or product (hipster, hacker, hustler!)
• 4 people: 1 frontend, 1 backend, 1 designer, 1 product
• 5 people: 1 frontend, 2 backend, 1 designer, 1 product or marketing
• 6 people: 1 front end, 2 backend, 1 designer, 1 product, 1 marketing
• 7+ people: it’s best when folks can align, i.e. two React developers, two Laravel developers, etc

Remember, the more people, the greater total person-hours there are, and the greater opportunity you have to present a more rounded product. You could even have one person dedicated to research, project management and the demo!

Team fit or team quality is another thing to consider:

• do people understand the idea, and does there feel like a natural synergy?
• do you respect and understand the people you’ve teamed up with, both in terms of skills and personality?
• is the team balanced, and does everyone have a role, and is capable of fulfilling that role?

There is nothing wrong if you feel the fit is not working, and are considering moving teams. It may be that another team is in a similar situation and your skills or personality would be more valuable there. But remember to be courteous, kind and professional about it; leaving a hole in a team may leave a sour taste in their mouth, so don’t add insult to injury.

Lastly, if you’re at the event to pitch an idea and are lacking the technical skills, you are essentially recruiting a team; be prepared to guide, project manage and be the enabler to help folks to do their best work.

Setup

Getting work done at a hackathon can be quite different to working in your usual setup.

You may not get a seat, or a desk, or regular access to power (hopefully they provide enough multi-sockets, but it doesn’t hurt to bring a spare!). You probably won’t have a second screen, so can you work happily on just your laptop screen? What happens if you don’t have a flat surface to work with a mouse?

It might be noisy, or cold, or you might feel a little overwhelmed with so many people crammed into a tight space. You should aim to be happy to collaborate with others, or take headphones if you need to cocoon yourself in code.

Additionally, you should make sure you’re considerate to others who may need to focus! Turn off your audio alerts, be conscious of those around you, don’t type like you’re paying tribute to Fred Astaire (opens new window) (I’ve been there, it’s not cool) and be mindful that folks may be feeling the time pressure, or lacking sleep on the second day.

Additionally, make sure the software you plan to use works on the laptop you’re going to use, and ideally do a dry-run perhaps at a coffee shop before the event. If you need access to code consider cloning any repositories or previous projects you need locally, so if there is an Internet outage you definitely have the code you need to hand.

Planning

At the event, it is absolutely crucial to keep planning to a minimum.

You are not building something to go into production for a client or actual users, you are building something in the time you have, with the team you have, to illustrate an idea, and that is where your focus should be.

If you exceed that and manage to build something genuinely production-ready, then brilliant, but do not get distracted with how cool it would be with this feature, or if it used that technology (unless your core idea is actually that feature written in that technology).

The more you over-plan, the more potential rabbit holes you have to fall into; do not start speccing the perfect API, do not get lost in UML diagrams, do not start writing documentation. The aim of in-event planning should be to get the team aligned ASAP so you can build the right thing for the demo (see also, yak shaving (opens new window)).

Execution

If you haven’t yet got the message of how critical a commodity time is at a hackathon, you must have skipped ahead 😁.

The execution stage of the hackathon is where it pays to be the most brutal. You’re going to have to write code you’re not proud of. You’ll have to copy and paste from Stack Overflow. You’ll need to butcher code you wrote on a project last year. You may very well feel dirty for some of the things you do, but moving quickly now will move you closer to the goal of getting it done.

Here’s a list in no particular order of things you should consider:

• do not use a new technology; stick to what you know and can write quickly and efficiently
• refactor an existing project you know well; project setup takes way, way longer than you remember
• don’t get bogged down with configuration, best-practices, the perfect linting setup or such like
• practice with core libraries or frameworks in a new project beforehand so you’re not reading docs on the day
• copy and paste a component library or set of utils you wrote in other projects to get up and running quickly
• leverage third-party code, for example a library demo or starter project (but be mindful of any over-complexity)
• use Chat GPT to write code for you, especially if you are stuck for more than 5 minutes

Your aim is to spend as little time as possible building the foundations or working through needless decisions. You should use any shortcuts or prior art to help deliver on the core idea for the final demo. If you think the project has legs for the future – fine – but hold your nose for now and keep iterating; you can refactor after the hackathon if that’s the way things go.

Of course, there is always a balance to be struck, but the takeaway is always takes longer than you expect – and the one thing you don’t have in a hackathon is time – you need to think laterally and stay mindful as not to waste it.

FWIW I’ve written about humans vs time before; you may find the following helpful:

• The work is never just “the work” (opens new window)
  A deep dive on why projects always take longer and a framework to improve future estimation
• Diary of a rapid application build (opens new window)
  Development diary and reflection on building a Trello clone in 8 hours
• Got Paper? (opens new window)
  A cheeky app to calculate your toilet paper requirements

The diary section (opens new window) of the rapid application build project is especially relevant for any hackathon; check the TL;DRs!

Demo

So you got to the end and it’s time to share your hard work, as well as see what all the other teams were working so hard towards. There’s certainly a bit of pressure but also it’s the time to enjoy the achievement of having worked with a team of folks and created something out of nothing.

The demo itself is important; you need to remind the audience of your original aim, share with them your execution on that aim, and possibly illustrate where the project could go from here.

What makes a successful project will vary from hackathon to hackathon, but ideally you will have something to show that at least captures the essence of the project’s aims. If you can make people feel the impact in their bones, or demonstrate potential of the idea, or even just make people laugh, so much the better!

Perhaps your style is to just “show and tell” or perhaps folks can test your project live, install on their phone, or you’ve gone the extra mile and there’s some physical interaction or other “wow” moment that makes people sit up and notice.

As mentioned earlier, it does pay to have someone on the team who can be in charge of the demo, who can practice their delivery and present it as a “finished” product. There’s certainly something satisfying about “closure” at a hackathon.

Also, think before about having a hashtag, something marketable, or otherwise viral interaction that folks could tweet about. It would be great if you and your team could leverage your hard work to live on past the event!

General advice

Up until now I’ve been fairly hard-nosed in sharing how you can get to the finish line on time, with something to show – but there’s lots more to a hackathon than just that.

Remember the hackathon is also about the people and the experience. Try to leverage serendipity; talk to people at the event, don’t be shy, and ask people about what they’re making (though some people may be a bit secretive).

Remember also, don’t be egotistical, or disparaging about others’ projects. A bit of competitiveness is great, but it’s supposed to be fun, and the more you put in, the more you will get out (sorry if that’s absolutely obvious!).

If you want an idea of how the day or couple of days might play out, then consider watching something like The Apprentice (opens new window) or Interior Design Masters (opens new window) to understand what it’s like to hear about something for the first time then have to deliver something finished within a very short timeframe.

There will be lots you don’t consider, and you will probably make mistakes along the way, but it’s a great experience and something you should absolutely do at least once in your career.

Afterwards

So what happens after the dust settles and you’ve made new friends and built the beginnings of The Next Big Thing?

Well, it’s up to you. You may decide to keep working on the project and to see where it goes. That’s what I did after an NHS hackathon and we even applied to a startup accelerator with it. We got through the first round of interviews but that’s where it ended. I did, however, make a friend for life and someone I text most days.

Some of the other hackathons ended up being fun for a day. And some ended up being portfolio pieces (opens new window). But whatever the outcome you will certainly learn some new things and learn a lot about working quickly (opens new window) and not getting bogged down in the detail, which is a huge skill to obtain.

Or maybe you really will go on and build The Next Big Thing and if you do, I will be rooting for you every step of the way.

Good luck!