How to plan a hackathon project in 24 to 48 hours

To plan a hackathon project, spend the first hour choosing one problem and one thing the demo will show, split the work into pieces that can be built at the same time, and decide in advance what you will cut at the halfway mark. Teams that plan this way finish with a working demo. Teams that skip it usually have three half-built features and a pitch that explains what the project would have done.

Spend the first hour on the plan

It feels wrong to sit and talk while other teams are already typing. Do it anyway. An hour of planning at the start saves many hours of rework, and rework is what kills teams around the eighteenth hour. Your first hour has four jobs: pick the problem, define the demo, split the work, and set two checkpoints.

Pick one problem and say it in one sentence

Judges see dozens of projects. The ones they remember solve a clear problem for a clear person. Write one sentence in this shape: "[Who] struggles with [what], so we built [thing] that lets them [do something]." If you can't write it, you aren't ready to build. If it needs the word "and" more than once, you are building two projects.

Check the problem against the theme and the judging criteria, which are usually on the event page. If originality is weighted heavily, an unusual angle on a small problem is better than a standard solution to a big one. If working technology is weighted, boring and solid wins.

Decide what the demo will show

Work backwards from the three minutes you will have on stage. Write down the story of the demo: the user opens it, does one thing, and sees one result. That story is your real scope. Everything that is not in the story is optional.

Then cut hard. A common mistake is trying to show five features badly. Show one flow end to end, and mention the rest in the pitch as what comes next. A demo that works beats a long feature list that doesn't.

Split the work so people are never waiting

With three or four people, the aim is that nobody is blocked for long. A split that works for many software teams:

• Person A builds the core feature the demo depends on.
• Person B builds the screens or the interface, using fake data until A is ready.
• Person C handles data, any outside service or model, and the glue between them.
• Person D, if there is one, owns the pitch, the slides, the demo script and testing, and helps wherever the build is stuck.

Agree the shape of the data between parts in the first hour, even as a rough sketch on paper. Most integration pain comes from two people assuming different things. Everyone should also be able to run the project on their own laptop by the end of hour two. If one setup problem blocks one person for three hours, you have lost a quarter of a teammate.

If your team is not all developers, that is fine. A designer who owns the demo story and a teammate who talks to judges are worth more than a fourth person writing the same code.

A sample timeline for 48 hours

This is a rough shape, not a rule. Adjust it to the event's start time and your need for sleep.

1. Hours 0 to 1: problem, demo story, split, checkpoints.
2. Hours 1 to 4: set up the repository, the project skeleton and a deploy target. Get "hello world" running and shown on a real URL early.
3. Hours 4 to 20: build the core flow, with the simplest version of each part.
4. Hour 20 (checkpoint one): does the main flow work end to end, even ugly? If not, cut features now, not later.
5. Hours 20 to 36: make it work properly, add the one or two things that make it special, and fix the worst bugs.
6. Hour 36 (checkpoint two, the freeze): stop adding features. From here it is testing, fixing and polish only.
7. Hours 36 to 44: write the pitch, record a backup video of the demo, and rehearse out loud at least twice.
8. Last hours: submit early, check the submission actually opened for the judges, and sleep a little.

For a 24-hour event, keep the same shape and divide every number by two.

Prepare for the demo to fail

Demos break. The wifi drops, the API is slow, the login you tested ten times chooses this moment to fail. Prepare for it. Record a short screen video of the working flow and keep it on your laptop. Keep some sample data ready so you are not typing live. Know what you will say if the live version doesn't work: "here is the same flow recorded this morning". Judges forgive a failed demo far more easily than a team that freezes.

Use what already exists

You have two days, so don't build what you can borrow. Use a hosted database, a ready login service, a component library and an existing model through an API. Spend your hours on the part that is unique to your idea. Check the rules first, because some events want most of the work to be new and require you to say what you reused.

Mistakes that cost teams the most

• Choosing the idea in the last minute of the first hour because nobody wanted to argue.
• Adding features after the freeze. Every one of them risks the demo.
• One person disappearing for ten hours into a hard bug without telling anyone. Set a rule: if you're stuck for more than an hour, say so.
• Ignoring the pitch until the final hour. A good pitch can carry an average build, and the opposite is rarely true.
• Not sleeping. A tired team makes more bugs than it fixes after about hour thirty.

The checklist

• One sentence for the problem and one for the demo story
• Work split with one owner per part, agreed data shape
• Everyone's laptop running the project by hour two
• Checkpoint at the halfway mark with permission to cut scope
• Freeze at about three quarters of the time
• A backup demo video and a rehearsed pitch
• Submission done before the deadline, then checked

Keeping the plan in one place with Vyam

Hackathon plans fall apart when they live in four heads and a chat thread. With Vyam you can describe the idea in a sentence, get a first draft of the tasks and a schedule that fits the hours you have, and edit it together in the first hour. Each task has one owner, the timeline shows what is late at the checkpoint, and if your code is on GitHub, pull requests appear next to the tasks they belong to. It has a free plan, and you don't need a card to start. The decisions that win a hackathon, which problem to pick and what to cut, are still yours.