As I was deciding what to write about next, I was thinking a lot about what makes a hackathon project great. I then dug a little deeper into how exactly someone could build a great project, and the role a hackathon places in shaping that. It made for something I’m pretty happy with.

Hackathons are a very tough thing to define. In many instances, I sort of refrain from using the word in casual contexts. The one time I didn’t, the person confidently agreed with me when they said “Oh hacking? I hear cybersecurity is big in Ottawa”. [1]

All jokes aside, it is quite hard to define. Saying it is a tech conference sells the event short, since - it excludes all the building. Even if you were to factor in all the workshops and speakers, you still wouldn’t really call it a tech conference, since the common association to those isn’t really “fun”. You also wouldn’t call it a student meetup, since that sells itself short in terms of the scale and the real world impact of many of the projects at the event.

The best way I’ve found to describe a hackathon is an event to inspire people to build. I leave out a lot here, I don’t really say build cool things (as I will explain later on, your project doesn’t really have to be cool). I also choose the word inspire, not help, since help makes it sound like in the absence of a hackathon, you would not be able to build something amazing. This is not the case. Hackathons are simply a vessel to inspire you to get to better understand your capabilities and aspirations as a builder.

But the word building get’s thrown a lot without really being explained. So what exactly are you supposed to build? Here is my best crack at it.

The first thing I’d point out is that, for all intents and purposes, it doesn’t really matter what you build. An unfortunate, but real, reality of hackathons - is that most people do not end up submitting a project. This is not the fault of the person. The time crunch of a hackathon, the no sleep, and the overall challenges that come with building something in that timeframe make coming up with a final product a tall ask. That is why, if you are able to submit something at the end of the 36 hours or so, that’s the real win that weekend.

However, if you’re looking for some more clarity on what to create, I find great hackathon projects generally fall into one of two buckets. The first are projects that are extremely technically proficient. The second are projects that solve a real problem people have. Let’s start by noticing the obvious, which is that if you’re able to create something that is in both these buckets you are almost guaranteed some type of recognition. This doesn’t translate well to the real world. When you are selling a product, it oftentimes does not matter how technically great it is. [2]

Many people find themselves in the first camp. I’m not quite sure why this is, but I have a couple of possible explanations. The first is that CS/SWE education places a unknowingly terrible pressure on the technicalities of software. This is important to a certain extent, but relevant to a hackathon - many people find themselves so caught up in what technologies, frameworks, packages to use that by the time the stack is created, you have less time to actually build anything. The second, is that there is this idea that the judges are likely to be more impressed if your project is really technically impressive. It’s hard to say whether this is true in a general sense. One thing that cannot be ignored, though, is that no matter how experienced the judges are, they are still human. Everyone likes seeing a well designed app, something that really brings out joy, something that has a nice demo to it. In other words: great technical chops can’t excuse a bad product, a great product can (sometimes) excuse bad technical chops.

So does this mean you shouldn’t try to make your project technically great? Of course not. There is obviously a place for choosing the right tools for the job. But only to the extent that you can explain your choices. That’s what is really important. If you can say with succinct clarity why you chose to do something the way you did, that tends to be good enough most of the time. Judges like to see the link between what you wanted to accomplish, and how you decided what to use to do that.

Less people find themselves in the second camp, projects that solve a real problem people have. This is a very hard thing to do. For starters, it’s hard to really think about problems that people have. It’s better if the problem you are solving is a problem that you yourself have, since that abstracts the thinking part away quite a bit (you are your own user). Thinking about a problem that other people might have is hard if you don’t talk to a lot of people about their problems (and in this context, you don’t really have all the time in the world). Also, it’s not exactly easy to think of a problem to solve with the clock ticking behind you. That’s why some people come into hackathons with a project idea in mind, and tailor it to fit a company track or challenge.

It’s important to remember that in most instances the problem you are solving is more important than your solution to it. If you can find a problem that doesn’t have a solution to it - then no matter how lame your solution is, someone is likely to see value in it since it’s better than nothing. As well, if you find a problem where the existing solution is not so great, any marginal improvement is likely to incite a reaction positive enough you would get some great results out of it. The marginal improvement doesn’t really have to be all that impressive either. I recently saw a great product on Twitter which is effectively a WYSIWYG markdown editor packaged in a nice UI with live-sharing features. Not really a technical leap by any means, but the UX was just so great, along solving an actual problem people had - that it got a ton of recognition.

It also doesn’t really matter how “cool” sounding your problem is. Cool, on trend, problems are great to solve since the relevance to the person you are pitching to is probably pretty high. But it’s also equally as likely that since the problem is trendy, this is not the first solution to it they have seen. This takes us back to square one in the sense you are now basically depending entirely on your product being a better solution as opposed to solving a better problem. Boring problems are great. Many hackathon projects implement AI into domains that haven’t really been all that explored yet. Something that I’ve seen more recently is the use of voice agents in various domains, even if said domains are not the most glamorous.

The final advice I can give is really work on having a great demo. Whether this is a video or a live one, it’s incredibly important. Extra points if there is a working product that the judges can play around with. People like seeing and interacting with things. Slide-decks are great, but relying on them to tell the whole story of your project may not work in your favor.

As you can imagine, a lot goes into trying to cultivate good projects. A significant amount of the onus is on the hacker to create something that is interesting. But as organizers, we play a big role in creating an environment that is conducive to the sort of “builder mindset” that inspires these great inventions.

One of the ways we do this at uOttaHack through community events. We run tons of fun events including karaoke, Mario-Kart competitions, Spicy-Noodle challenges - just to get people to have fun. You want to be in a mindset of enjoyment in order to build something interesting. It’s also a great way to get people to meet each other, which contributes more to finding great ideas. If nothing else, you walk away from the hackathon having met new people with new bonds, which is a far greater value than any project could provide.

The second way we do this is an overall mindset shift. A big focus at uOttaHack is placed on the hacker. So much of what we do is to get hackers, the first time ones, the best possible experience learning more about their aspirations and interests in technology. If we can do this through creating an environment free of pressure and expectations, and replace with it fun and engaging events that make them want to come back and learn more - that’s a great success.

Notes