Context

After relocating to the Bay Area for my first year of university, I swapped my priorities:

Previous: 100% long-term work, 0% short-term work Current: 30% long-term work, 70% short-term work

I previously worked on small features on large codebases, like Minigames. Now, I more frequently work on smaller-scope, but high impact problems/projects I want to take a shot at solving.

Hackathons

Hackathons are a great way to motivate yourself to actually get started on a project. You typically may want to solve a problem, but put it off for days. Especially if you are limited by a tight schedule (work/school).

If you have a Saturday off, and want to bring your idea to life, get your friends together and attend a hackathon. It's much easier here in the Bay Area, where there's an event going on quite literaly every day. But, most big metro. areas in the U.S./foreign have companies or organizations that host hackathons on a regular or seasonal basis.

Finding an idea

Organizers typically provide problem statements in their details. You want to adjust your idea based on the technical complexity or backstory the organizers may want.

For a 3rd-place winning project, I generated my idea through Claude. I emphasized technical complexity and ended up with an idea that allowed me to build an S3-like tiering system for browsing history.

It's important that, when considering this balance of backstory and technical complexity, to also consider your level of skill.

Time-constraints

Something interesting I do is that I avoid hackathons longer than 12 hours. It may seem great having 24-48 hours for a hackathon, but when you value your sleep (like I do), you aren't able to take full advantage of that 24+ hours. Meanwhile, others may down a couple of Red Bulls/Celcius' and grind through any issues they have throughout the night(s), even if they aren't super skilled and are only vibecoding.

Although the time-constraint of a less than 12hr hackathon is challenging, if you are really locked in and know exactly what you want to build, you can definitely do it.

Scope

Technical complexity directly ties in with the scope of your project. I personally define scope as the amount of independent components that need to be integrated together in your system/project.

There have been hackathons where I have gone too big of a scope. In these hackathons, I planned out 2 or more individual components, and they required intensive integration work to get working together. And, even when we finished integration, there were edge cases or state management issues that made it an unreliable demo.

I learned that it's best to keep your hackathon project less than 2 components.

Demo

The demo is always the most important part. You could make a technically complex project, but fail at your demo. No one will see past it.

You should be engaging in your demo, and it should be fluid. It should have some sort of backstory. It should obviously appeal to your judges. Try to have fun on stage.

Examples

You can find my Hackathon demos on YouTube. You can find the code on our GitHub.