How To Win A Hackathon
Our team recently won the Olim in Tech Hackathon. Twenty-five teams entered and over 100 people participated. This article discusses what we learnt from it. The second half is more technical, so if that’s what interests you feel free to skip the first few sections.
Despite the bold title, this isn’t the definitive guide to winning a hackathon, I’m just hoping to get some good SEO as that’s the term I looked up before the event myself. I’m no hackathon expert. Learn from what you think makes sense and discard the rest 😀.
My situation is somewhat unique in that I’ve also organised a hackathon at which I was also one of the judges. I’ll also be sharing experiences from that event and what I took from it leading into this one.
For those of you that don’t know what a hackathon is, it’s an event where you build a product in a short span of time (usually 1–2 days). Here’s a video of what we built in 14 hours:
Team
I’ll start with the team. As every startup guru will tell you, “it’s all about the team!”
Our team consisted of a designer, presenter, frontend developer, and full stack developer. We had a very strong team going into the event with lots of complimentary skills.
Each team member played an important part.
The developers, Aaron and I, wrote the code.
The designer, Allie, not only made the product visually appealing, but worked through the UX, product features, and tightened the presentation.
Daniel, our main presenter, worked on the deck and led the final presentation.
All four of us were involved in product discussions.
Each of our team members played an integral role, and I don’t know if we could have won had any one been missing.
Having said this, you don’t need a multi-person team to win an event. At the blockchain hackathon we ran a few months ago, the winner was a solo developer. He did both the development and pitch himself. (On a related note, despite the common trope, a startup doesn’t need multiple founders to succeed either. Amazon has a single founder in Jeff Bezos. VCs and accelerators would do well to remember this. Want more data? See here.)
Preparation
The hackathon we attended was a shorter than most. Hacking started at 7pm and ended at 9am the following day — a total of 14 hours. We had to be well prepared going in.
Our team met twice before the event to discuss ideas. We had six ideas and narrowed it down to one. This saved us valuable time during the event and meant we could get into hacking away from the get-go. There were still items to figure out during the event, but the rough idea of what we were going to build was already agreed upon before the event started.
Pitch
The presenter may be the team member that adds the least obvious value, but winning an event like this is all about the pitch. Nobody cares how good the code or product is if you can’t present it well.
Our pitch had to be a strict three minutes long. Most teams had a single presenter, but we actually had three team members members involved in the pitch. Both options work.
Daniel started off the pitch by describing the general idea, then Allie introduced the product, and I finished the pitch with a quick live demo of the app. After our pitch was over, Daniel fielded questions from the judges.
In general it’s risky to demo a product live. Have a video ready as backup as something always seems to go wrong. Losing internet connection during the demo would have ruined it. This isn’t advice we took ourselves, but thankfully we didn’t have any technical difficulties or bugs pop up during the demo.
When running our blockchain hackathon a few months ago, one of the biggest takeaways for me was the importance of doing a product demo in the pitch. The winner of the blockchain hackathon gave a live demo in his pitch and that impressed the judges far more than those that spent all their time talking at them.
The two biggest items we got right in our pitch:
- The presentation (and app) design was by far the best.
- We had a great and charismatic storyteller leading the pitch.
Judging Quirks
The judging criteria can have a major impact on where you finish. The judges at a hackathon are asked to rate you out of 10 for certain criteria. The result is that they may like one team more than another team, but based on the voting criteria, the team they prefer may not score highest.
I don’t know how our team scored in each category, but I do know that when I was judging a few months ago, this had an impact on the results.
This point may not be fully clear without a concrete example, but the takeaway for hackathon contestants looking to win an event is to aim to maximise their scores in the categories you’ll be judged on.
Tech Stack
The technologies we chose to use are the ones I’m most familiar with as a full stack JavaScript developer. There are a lot of great alternatives out there, so use whatever works for you. Many of the ideas below will apply to a variety of languages, a few are JavaScript/TypeScript specific.
Boilerplate
As a freelance consultant I’ve been involved in starting a lot of new projects. Likely more so than the average developer that spends most of their time fixing bugs and adding new features to existing projects. For maximum efficiency in getting a new project up and running we use a boilerplate (this will often change in real projects, but it’s a good starting point). This is what we used for the hackathon too:
If you’re interested in the principles behind this boilerplate, I wrote more about in a previous article.
There are a lot of popular hackathon starter kits out there. One of the most popular with 28,000 starts on GitHub is by Sahat:
I recommend getting comfortable with one of these boilerplates before an event starts as there’s a learning curve to using one. I chose to use our own boilerplate, because I knew this would allow us to develop at maximum speed. Building your own boilerplate is a great idea as you’ll be extremely familiar with it.
Expo (React Native)
We built our app using React Native. There was some discussion among the team whether we would build it as a mobile web or native app. We decided to go with native (React Native) as it would enable us to build a more impressive product.
For anyone that has used Expo you’ll know it’s a dream to use. You can be up and running with a mobile app that works cross platform within minutes:
It’s super easy to publish updates to your app over the air, has tonnes of functionality ready for use out the box, and there’s a great team behind it.
Expo has some limitations. The major one is that you can’t add native code to an Expo app unless Expo already supports it. You can detach from Expo to make it a regular React Native project, but then you lose many of the benefits of using Expo. For a hackathon this shouldn’t be a concern. If in the future your project blossoms into something larger and you need a feature that Expo doesn’t provide you can always decide to detach then.
Node.js
The backend was built in Node.js. We spent minimal time on this during the event. The biggest advantage of using Node.js is utilising a single language (JavaScript) across the stack.
Other options for backends are things like AWS Amplify and Firebase. A lot of what these platforms do our boilerplate provides in any case so I chose not to use them. These are a great option though. Using Amplify you can be up and running very quickly with a full authentication system running in under 20 minutes (including all the UI). Some disadvantages of using Amplify are that you’re tied into AWS, you lose full control of the backend, and it uses an Amazon specific language called VTL for parts of it. For a hackathon it’s a very good option as long as the VTL doesn’t hold you up if you need to add more advanced functionality.
TypeScript
TypeScript is JavaScript with static typing. This protects your code from many potential bugs and also helps with autocompletion and as a form of documentation.
The second developer on our team, Aaron, was new to TypeScript, but we decided to go with it anyway. We used TypeScript with strict mode turned off so we could write plain JavaScript where needed. He was sitting next to me during the event so if he ever ran into trouble we could get the TS specific issues solved very quickly. TypeScript’s any type is also your friend here. For larger projects you may look to avoid it as much as possible, but during a hackathon it’s important that the language and tooling you use don’t slow you down as time is so limited.
MongoDB / TypeORM
For the database we used MongoDB with TypeORM. We could have used any database, but this is what I have the most experience with so it’s what we went with. TypeORM support for MongoDB is not great. I wrote a full article on that here, but for the purposes of this event it was fine.
When using TypeORM you don’t need to define the database schema and TypeScript types twice. It really shines when used with TypeGraphQL which we’ll talk about next.
TypeGraphQL / GraphQL Code Generator / Apollo Server / Apollo Client
We used GraphQL for our API.
TypeGraphQL is a library that allows you to write your GraphQL schemas and resolvers using TypeScript classes. The schema definition is automatically generated for you so you don’t have to write it.
Combined with TypeORM, you can define both the GraphQL type and the entity in a single class — no need to jump between multiple files to add or rename some properties.
Using GraphQL Code Generator we even get TypeScript types and fetching logic generated for us on the client.
This is truly magical and what you can achieve with 10 minutes of coding will take some teams a few days to produce.
Here’s some sample code. In the first file we define the MongoDB schema, GraphQL type, and TypeScript types. In the second file we define the GraphQL resolvers:
You can see a more full example in our boilerplate repo.
Using GraphQL Code Generator, all we have to do is define the GraphQL query and the fetching logic with TypeScript types is generated for us:
The useItemsQuery is generated for us by a running a single line in the command line with all full TypeScript typings.
Plop
We go even further with code generation using Plop. We didn’t use it on the client during the hackathon (although the boilerplate does include some client generators), but did for the backend. With one command we have the three files we use for each entity on the server autogenerated for us.
AccountsJS
For authentication we used AccountsJS. The problem AccountsJS aims to solve:
Meteor framework had a plug and play approach for its monolithic framework that saved a ton of work that is traditionally done by any development team, over and over again.
AccountsJS aims to provide a plug and play log in system for your full stack JavaScript project. Our boilerplate is already set up to work with AccountsJS.
We didn’t actually show off any log in or sign up functionality in our hackathon demo, but it was there in the background. For other hackers, you can likely get away without an authentication system at all, but it’s nice to have and if you want actual people using your app you likely need one.
UI Kitten
UI Kitten is the amazing open source UI library we used. It’s super sexy. By far the best looking React Native UI library out there. (The equivalent of Bootstrap, or Ant Design on web, but less mature).
They also have an open source app called Kitten Tricks that demos their available components and many ready made screens. We used these ready made screens for our sign up screen and profile page (although we didn’t demo either of these in our presentation).
Cloudinary
For image upload we used Cloudinary. It’s far nicer to use than something like AWS S3. One really cool Cloudinary feature we used was image filters. To darken an image, all we had to do was adjust the URL and the filter was automatically applied by Cloudinary. This saved us the trouble of working out how to apply a filter in React Native.
As an example, to darken an image you add the following to the image url:
e_brightness:-60
To lighten it a bit you add:
e_brightness:30
Cool stuff. There are loads more filters available too.
Deployment
We deployed with Docker to DigitalOcean and used MongoDB Atlas free tier to host the database. PM2 is another nice option I like for deployment. We could have run the database on the same droplet as the server, but using Atlas gave us a nice user interface to manipulate the database with ease.
Expo handled publishing of the React Native app for us. If you’re deploying a static frontend use Netlify or Now.
Deployment can be tricky. Don’t waste time during the event working out how to do it. Practice in advance if needed, so you don’t run into unexpected issues and waste valuable time during the event.
Future Of Our App
So what’s the future of our app, Shopitt?
As a first step we’d like to properly launch it on the Android and iOS app stores.
There are a few items to iron out to turn it from a hackathon MVP into an MVP people can make use of.
If you’re interested in getting updates on our progress, follow me here or on Twitter (@elie2222).
Have any hackathon tips you’d like to share? I’d love to hear them in the comments.
About Me
I‘m a full-stack developer and founder of Skilled. Feel free to reach out at elie.tech.
Newsletter
Stay up to date by subscribing to my newsletter.
