What is a Hackathon?

A hackathon is an event where small teams build something in a short time. Usually an app, a game, or a quick fix for a problem. The word mashes "hack" (build something fast and a bit scrappy) with "marathon" (you keep going).

You already did the hard part once. You shipped a full Python Kingdom RPG, save system and all, from an empty file. A hackathon is that same instinct, just under a clock and with teammates next to you.

You don't need to be an expert. Honestly, the best ones are where you learn a thing or two while building.

A hackathon rarely produces polished demos. More often you get a few teams still arguing about the idea at hour two, and one team that has already shipped a working prototype because they picked the smallest possible problem. Guess which team usually wins.

How it Works

The shape is always the same, even if the schedule looks different.

1. Team formation - You group up with 2-4 classmates.
2. Project selection - The team decides what to build.
3. Building - You work together to create the project.
4. Presentation - You show what you built to the other teams.

Step 2 is the one nobody warns you about. There's usually an awkward 15 minutes where everyone has an idea, nobody wants to be the one to pick, and the clock keeps ticking. Teams routinely burn an hour here. Pick something boring on purpose if you have to, then start. You can always trade up at hour three. You cannot get hour one back.

Team Roles

In a hackathon team, each person can have a different role:

• Programmer - Writes the code.
• Designer - Handles how the project looks and feels.
• Project Manager - Keeps the team organised and on track.
• Presenter - Prepares and delivers the final demo.

One person can have multiple roles, especially in small teams. More often than not, the Presenter is whoever sounds least nervous in front of strangers, not whoever knows the code best. That's fine. The judges are watching the screen, not auditing your commits.

Brainstorming: How to Generate Ideas

Before the hackathon, think about problems you'd like to see solved. Some useful questions:

• What annoys you in daily life that could be solved with technology?
• What game or app would you love to exist?
• What problem do your classmates have that a program could solve?

Write everything down first. Pick later. Most teams kill their best idea in the first 10 minutes because someone says "that's too hard" before anyone has tried to scope it down. The idea isn't too hard. The full version is. There's almost always a smaller version that fits in a weekend.

What is an MVP?

MVP stands for "Minimum Viable Product", the simplest version of your project that still works. At a hackathon you don't have time to build everything, so you ship the core first and add the rest if there's time.

For example, if you want to make a quiz app:

• MVP: Display questions and check answers.
• Nice to have: Score, timer, categories, leaderboard.
• Extra: Sound, animations, multiplayer.

A classic trap is building the leaderboard before the questions even work: a beautiful empty table with nothing to put in it, and two hours gone. A good rule of thumb: if the demo doesn't run end to end by the halfway mark, cut something. Usually the thing you're most proud of, because that's the thing eating all your time.

If you only ship the MVP and nothing else, you still have a demo. If you ship three "nice to haves" and the core doesn't work, you have nothing to show.

Before the Day

Next lesson we plan a real one together. We'll take a single idea, "Quiz Master", and walk it from a vague pitch to a scoped MVP you could actually finish in the time you have. That's the part people get wrong, not the typing.

You can already write the code. Fifteen lessons of it, in fact. What you haven't practised yet is aiming it: choosing a small enough target so the code you write actually adds up to a demo by the end. That's what planning buys you.

Aim for the boring idea, not the impressive one.