Before the Event: Preparation That Pays Off
The teams that look freshest at hour 20 are often the ones who prepared the most at hour -48. Pre-event preparation doesn't mean cheating — it means not wasting hackathon hours on avoidable setup.
- Form your team before the event. Team chemistry is hard to build during crunch time. Meet beforehand, discuss interests and skills, and align on a rough project direction.
- Set up your dev environment. Node, Python, Docker, whatever stack you plan to use — have it installed and tested before you walk through the door.
- Read the judging criteria. Most hackathons publish them in advance. Know whether impact, innovation, technical complexity, or design weighs most.
- Review sponsor APIs. Sponsor prizes often require using a specific API. Skim the docs, test authentication, and identify gotchas before the clock starts.
- Prepare allowed boilerplate. Auth scaffolding, database setup scripts, and UI component libraries are often allowed. Bring what you can.
- Sleep well the night before. You will make better decisions, write cleaner code, and present more confidently when you're rested.
Picking the Right Idea
Idea selection is the highest-leverage decision you'll make. The wrong idea — too broad, too ambitious, or solving a problem nobody has — can doom the project before a line of code is written.
A good hackathon idea has these properties:
Solves a real, specific problem
Not "improve healthcare" but "help patients track medication adherence via SMS". The more specific, the more credible.
Demonstrable in 2 minutes
You need a live demo. If the core value proposition can't be shown in 2 minutes, the scope is too large.
Achievable given your team's stack
An idea requiring a skill nobody has is a bad idea, no matter how clever. Play to your team's strengths.
Has a clear target user
"Everyone" is not a user. Name a specific person who has this problem today.
Uses the event theme or sponsor APIs strategically
Aligning with sponsor APIs can win bonus prizes and score points with judges even if your main idea is modest.
One useful test: can you explain the idea and its value to a non-technical person in 30 seconds? If not, simplify until you can.
Team Formation and Role Assignment
A balanced team of 3–4 with clear role ownership consistently outperforms larger teams with fuzzy responsibilities. At minimum, cover: frontend/UI, backend/API, and either a designer or ML engineer depending on your project type.
Spend your first 20 minutes on a team kick-off: each person states their strongest skill and preferred focus. Agree on roles and write them down. Invisible role expectations become visible conflicts under pressure.
Need to find teammates? Use the event Discord, Devpost's team-finder, or our free HackMate platform where you can post a profile, list your project, and apply to open teams before the event starts.
The First Two Hours: Set Up for Success
The first two hours set the tone for everything that follows. Teams that spend this time well are still building productively at hour 22. Teams that spend it arguing about stack choices or chasing a new idea are behind by noon.
Checklist for your first two hours:
- Lock in the idea — decide by consensus, then commit
- Create a shared repository and agree on branching strategy
- Set up your communication channel (Discord voice, Slack, or in-person)
- Define the MVP: the absolute minimum that demonstrates the core value
- Assign tasks — each person should have a clear first task within 30 minutes of the hack starting
- Agree on check-in cadence (every 3–4 hours works well)
Build Your MVP First, Features Second
The MVP rule is the most violated principle in hackathons. Teams spend the first 18 hours building features and then scramble to wire everything together in the last 6. The correct order is: make the core flow work end-to-end first, then add features if time permits.
A working MVP means a user can: input something → something meaningful happens → a result is shown. Everything else is a feature. Build the skeleton before the flesh.
The MVP Test
If you demoed what you have right now, would judges understand the core value proposition? If yes, you have an MVP. Now polish it instead of adding features.
Cut scope aggressively and early — it's always better to have one feature that works perfectly than five features that half-work.
Time Management During the Hackathon
Time is the scarcest resource at a hackathon. Here is a rough time allocation for a 24-hour event:
| Hours | Focus |
|---|---|
| 0–2h | Team kick-off, idea lock, repo setup, task assignment |
| 2–10h | MVP build — core feature, end-to-end working |
| 10–14h | Polish MVP, add highest-priority secondary features |
| 14–18h | Bug fixing, integration, UI polish |
| 18–20h | Feature freeze — stop adding, start testing |
| 20–22h | Demo prep, pitch rehearsal, slide deck |
| 22–24h | Final polish, dry run, rest if possible |
The feature freeze at hour 18 is non-negotiable for teams serious about winning. The last 6 hours are for presentation quality, not feature count.
Nailing the Demo and Pitch
The demo is where your project either lands or gets forgotten. Judges see dozens of projects — a clear, confident, well-rehearsed presentation stands out immediately.
Open with the problem, not the solution
Start with one sentence describing who has this problem and what it costs them. Judges need context before they can appreciate your solution.
Show, don't tell
Live demo beats slides every time. Click through the actual working product. If there's a risk of failure, have a recorded backup video ready.
Narrate what the user is experiencing
As you demo, say "a user lands here and sees..." — this helps judges follow the flow and visualises real usage.
State the technical innovation
Briefly explain the interesting technical decision: "we used X to achieve Y, which normally requires Z". Judges include technical evaluators.
End with impact
Close with the potential reach or impact of the solution. Make judges feel like the problem is bigger than a hackathon project.
Rehearse at least twice
Timed rehearsals reveal what needs cutting. Most teams talk too fast when nervous — rehearsal fixes this.
What Hackathon Judges Actually Look For
Judging criteria vary by event, but the following factors appear in almost every rubric. Weight your effort accordingly:
| Criterion | What Judges Are Asking | How to Signal It |
|---|---|---|
| Impact | Does this solve a real problem? | Name a specific user + quantify the problem if possible |
| Innovation | Is this approach novel? | Explain what makes your approach different from existing solutions |
| Technical execution | Does it work? Is the code quality reasonable? | Live demo; mention any interesting technical decisions |
| Design | Is it polished and usable? | Clean UI, consistent visual language, smooth demo flow |
| Presentation | Is the pitch clear and compelling? | Strong opening hook, clear value prop, rehearsed delivery |
| Feasibility | Could this be built into a real product? | Mention a realistic path to an MVP or beta |
The Most Common Mistakes (and How to Avoid Them)
Idea scope too large
Ambition is good; overscoping is fatal. Halve your initial scope. You can always add more if time permits — you cannot halve your scope at hour 20.
No working demo at presentation time
The most common and most damaging mistake. Prioritise a working demo over every feature. A broken demo is worse than no demo.
Skipping the pitch preparation
Allocate at least 2 hours to the pitch. Assign one person to own it from hour one, not from hour 22.
All-nighter thinking
Most people make significantly worse technical decisions after 20+ hours awake. A 4-hour sleep block often produces more productive output in the remaining hours than grinding through the night.
Premature optimisation
Don't spend 3 hours making your database queries faster when the UI is still broken. Demo-correctness before performance.
Ignoring the judging criteria
Read the rubric and design your pitch to address each criterion explicitly. Judges scoring on a rubric give credit for what they can see.
After the Hackathon: Making It Count
The hackathon ends, but the value doesn't have to. Teams that capitalise on the momentum often build real products, launch on Product Hunt, or turn the project into a portfolio piece that gets them hired.
- Clean up the repo and write a good README. You will thank yourself when you revisit it in six months.
- Post the project on Devpost, LinkedIn, and Twitter/X. Document what you built, what you learned, and what you'd do differently.
- Debrief with your team. What went well? What slowed you down? A 20-minute retro improves every subsequent hackathon.
- Keep in touch with your teammates. Hackathon teams that stay connected often collaborate again — or refer each other for jobs.
- Consider continuing the project. If you got positive feedback from judges or users, the hackathon version is often a solid starting point for a real product.
Frequently Asked Questions
How do you do well in a hackathon?
Pick a focused, scoped idea. Form a balanced team with clear role ownership. Ship an MVP first, then polish. Freeze features 2–3 hours before the deadline. Rehearse the pitch. Sleep at least 4 hours.
What makes a good hackathon project?
It solves a real, specific problem. It has a working live demo. It's explainable to a non-technical person in 30 seconds. The technical approach is interesting or novel enough to impress judges.
How do you prepare for a hackathon?
Form your team in advance. Set up your dev environment. Read the judging criteria and sponsor API docs. Bring allowed boilerplate. Sleep well the night before.
What do hackathon judges look for?
Impact (real problem), innovation (novel approach), technical execution (working demo), design (polish), and presentation (clear compelling pitch). Most rubrics score all five — address each one explicitly.
Is it better to have a complex or simple hackathon project?
Simple and working beats complex and broken every time. The best projects are laser-focused on one core feature that works flawlessly during the demo.