Choose a painful, narrow problem
A broad theme like healthcare, finance or education is not a project. A winning hackathon idea starts with a small user who has a specific job and a visible failure in the current workflow.
Write the problem in one sentence before you write code. If the sentence needs a paragraph of context, the project is still too wide for a weekend.
Scope the demo before the stack
The demo is the product during a hackathon. List the screens, inputs, outputs and handoffs that the judge will see, then build only those parts first.
You can use manual data loading, seeded examples and simple hosted services. The goal is not production architecture. The goal is proof that the idea works under pressure.
Make the technical risk legible
Judges need to understand what was hard. If you use retrieval, agents, computer vision or hardware, show the before state and the after state clearly.
A short evaluation table beats a vague claim. Show accuracy, latency, cost, false positives or a concrete user time saved.
Rehearse like the build depends on it
A working app can lose when the demo meanders. Practice the first thirty seconds until the problem, user and result are obvious.
End with a credible next step. Judges do not need a fantasy roadmap. They need to believe the project can survive one more week of work.
< read by a human · updated as things change >
browse hackathons