Hacking Hackathons

July 30, 2023

As I sank into a bean bag in the corner of Microsoft office in Bangalore back in 2011, I slowly came to terms with reality- we had no plan and no technical knowledge of how we were going to build our idea. No one thought our idea was useful, to be honest. We were solving a problem nobody had.

Several hackathons later, after being on both sides of the judging table, I have formulated a rubrik that I now stick to.

While some of these are things you could do on the day of the hackathon, some require a few months of preparation.

So this might be useful whether or not you have a hackathon coming up.

Know exactly what you’re trying to solve

If the hacakthon has a theme, find a problem somebody would pay to solve. This is easier said than done.
Once you know the problem, FRAME the problem as something you could solve.
Framing is how you look at the problem. Its a perspective that gives you advantage.
A robot that misinterprets your commands is frustrating. A robot dog that does the same is cute and forgivable.
That’s the power of framing.

Know what you’re NOT trying to solve

Set boundaries and decide what you will not solve.
Declare this early in your presentation too.
Judges might ask you about your decision, but they won’t penalize you if you have thought this through.
It’s infinitely easier to build once you decide what not to build.

Have a go-to tech stack

Do not find out what tools you will use on the day of the hacakthon.
Do not use vim or docker if you can’t comfortably use it everyday.
Build experience in one tool that you can use for backend and one for frontend.
My preferred stack is FastAPI for backend and Svelte for frontend. I also use Docker.
I don’t use a database if I can help it- you can get a lot done working with json or csv files.

Avoid databases. Use files.

Forget PostgreSQL, and ORM adapters. No, not even Mongo.
You essentially eliminate all database layers, and associated code so you can work faster.
JSON should be good enough for whatever you need (user tables)
If you need more than JSON files, your idea probably can be distilled further.

Build a story around your product

People have a problem in the real world. They come to your product to solve their probem. Then they go back, out into the real world.
You need to take the judges through this entire journey.
Clearly indicate how users lives are changed because they went through your product.

Everyone plays to their strength

Backend guy does backend. Do not make him learn a new framework.
The web developer builds a web page. You don’t ask him to learn React Native. You ask him to build a webpage and demo it in a smaller window to mimic a mobile app.

Logins are unaffordable

Don’t build login screens.
To show roles, use different webpages with the username clearly visible on the screen. Switch tabs announcing and drawing attention to the role change.
This is one place people regulary waste a ton of time
Logins have almost zero pros if all goes well, and will terribly screw you up if it fails.

Cut scope, cut scope, cut scope

You will meet dead ends. You will run out of time.
You will realize you can’t pull off your mind blowing feature in the next hour and a half.
Someone will fall sick or sleep of exhaustion in the last hour.
When this happens, ruthlessly cut scope. You have permission to drop that killer feature and deliver what you can.
You can still sell your feature in your slide deck AFTER you demonstrate a basic working prototype.
The best presentations are where you take something small and deliver it extremely well.
The bad ones are where the presenter goes “we also do… , and also …, and also…”
This means you do not understand what you are trying to solve.
So cut away. It’s actually good for you.

Onboard the Deck

Have a minmal deck. 5-10 slides, mostly pictures or diagrams.
Do not read what is in the slides.
People start dying inside if your slide has more than 20 words in them.
Clearly state how you framed your problem in your opening slide.
Perpare something extra to share orally on top of certain slides. This content should not be in the slides.
This should be something extremely insightful, for only the people actively listening to you.
A tiny story or a failed attempt will fill this plenty.
This makes you look autoritative and someone who has explored much more than is presented.

Make it look good

It pays to learn a little about design (even if you suck at art).
Learn about serif and sans-serif fonts.
Learn about color palettes, and explore color palette generators.
Learn about spacing and grids.
The idea is to make it look clean and elegant, not haute couture.

Share what you’ve learnt in the process

After a clean demo, if the audience is interested (you will see from their faces), mention how you iterated. Keep slides for this but be ready to skip them if you are running out of time, or they out of patience.
It is very important you keep this for the end, and not linearly as it happened to you. People will only be interested in your iterations once they see your demo and are impressed.
Tell them what worked, but especially what didnt work. Show them the grunt that went in. Show edge cases. Make them respect your work.

Sandwich your demo

I start with the deck, jump into the demo and back into the deck.
I do this, because people need some context about our approach before they can appreciate the demo.
Sometimes the judges are distracted filling out some forms of the previous presentation too. You don’t want them to miss your demo by placing it too early.
Start with the problem and framing and quickly jump into the demo.
The come back to the slides and share all the juicy bits.

Finally, recap

Nobody is more interested in your presentation than you.
People probably forgot your framing statement by the time you reach your last slide.
Some people, even judges, probably only got interested halfway through your presentation.
Give them another chance to catch up.
In the last 1 minute, go back to your slide 1 and quickly surf all the way through to the last slide, condensing each slide to one line.
Leave no one behind.