Everything we learned winning hackathons.

Do

• Map the basics: location, duration, food, sleep setup, overnight rules, transport, submission deadlines, and any multi-stage structure.
• Identify the parts that will affect energy and focus, because these constraints shape the quality of every later decision.

Do

• Aim for 2-4 people with the roles covered: at least two people who can build, one person with strong design/product judgment, and one strong pitcher.
• Roles can overlap, but do not leave a core role uncovered and do not fill the team with people who only contribute ideas.

Do

• Make the goal explicit before the event: everyone must be down to win, not vaguely interested in learning, networking, or having a relaxed weekend.
• If people want different outcomes, decide that early instead of discovering it when the hard tradeoffs start.

Do

• Everyone should commit the same amount of capacity, preferably all in: same seriousness, same availability, same willingness to do the uncomfortable work.
• This is not about skills, it is about presence. Avoid a team where some people go all the way while others split focus or show up only when it is convenient.

Do

• When the direction of the challenges is known, build domain knowledge or get access to experts who can explain the real constraints, users, and failure modes.
• Do not start building. It is often against the rules, and the first conversations at the hackathon can invalidate most pre-built assumptions.

Do

• Arrive early and claim a place that supports focused work: quiet enough, enough space for discussions, enough power, and close enough to the people you need to talk to.
• Bring whatever makes the workspace actually usable, such as chargers, adapters, monitors, headphones, and sleep gear if the event runs overnight.

Do

• Map the format: single stage or multiple stages, challenge-specific or overall winner, submission mechanics, pitch format, and who decides at each step.
• Identify who judges and their background: founders, VCs, operators, etc.
• Read their preferences and biases, not just the written criteria.
• Winning is an emotional buy first, then justified with logic. Judges want a team to win, then find arguments why they should win.
• Maximize emotional buy-in: become the team they like and love. Be kind, be genuinely interested in the problem, the case, and them. Be someone they want to see win and support.
• Provide the logical justification: be the best team.

Do

• First understand who the jury is and which criteria they will actually grade emotionally, then pick the challenge that lets you satisfy those criteria best.
• Choose your challenge based on jury preferences and team strengths, not just which one seems cool to build or easy to execute.
• Avoid technically impressive but irrelevant solutions.
• Avoid challenges too narrow, where all solutions look the same and you can't be extraordinary.
• Avoid challenges too wide, where ideation becomes a random winning factor.
• Ideate based on what the jury wants to see and real-world impact. Prefer solutions that could realistically work over 'bullshit apps' nobody would use.

Do

• Interview case providers, the jury if possible, and actual customers. Treat them like customers, not as people who automatically know the right solution.
• Ask the discovery questions: who are the stakeholders? What are the biggest current problems? What solutions were tried before, and what worked or failed?
• Find out who inside the company enables progress, and who blocks it.
• Talk to experts from LinkedIn or your network, and capture proof that you did it: photos of calls, notes, quotes, and names where appropriate.
• Make sure the whole team understands this phase: the case providers should do most of the talking. You are there to ask questions and avoid building in the wrong direction.

Do

• Build a business case, not just software.
• Focus on real impact and organizational relevance.
• Write the one-sentence problem in the customer's language, name the persona, and their current workflow.
• Define why now: new technology, changed regulation, sponsor urgency, or newly visible pain.

Do

• Set up the repository properly: a stable build at all times, Husky pre-commit hooks, and code that builds before commit.
• Lock the tech stack early.
• Define rules: notify immediately when stuck, no silent blocking.
• Assign clear ownership per task.

Do

• Work backwards from the pitch, and define early: problem, persona, business value, and product narrative.
• Only build what will be shown in the pitch: if it's not in the demo, it has zero value.
• Focus on a clear user journey so the audience understands from start to finish how value is created, from problem to outcome.

Do

• Conduct early user/customer interviews: go on Apollo, find target customers, call them, take photos of calls and notes.
• Extract real workflows, real pain points, and language for the pitch.
• Integrate it into both the product and the pitch.
• Use it as a differentiator: it shows real market research, a very strong signal for the jury.

Do

• Parallelize product development and pitch development, and continuously align what is built vs. what is pitched.
• Ensure enough food, enough water, and proper rest. Empower the team continuously so they can deliver maximum value.
• Develop the pitch from an early stage, not as a last-minute task, and continuously refine the storyline and messaging. Assume the jury understands the case worse than you do, take them on a journey.
• Audience-test the pitch with competitors on another case or someone outside the team. Ask basic questions afterward: who is the customer, what is the problem, and how do we solve it? If they don't get it, iterate. You get one real shot at the pitch, and if you do fewer than 15 full run-throughs, you probably overvalue the coding part of hackathons.
• Protect the pitcher: they must sleep the most and be fully sharp. A tired pitcher equals wasted team effort.

Do

• Freeze scope early: no new features.
• Goal: a working version hours before the deadline.
• Consolidate into one working version and prevent broken merges.
• The leader enforces the final cutoff.

Do

• Ensure the demo is deterministic.
• If it's a live demo, implement a reset script and test repeatedly: run, reset, run again.
• If multiple people participate in a roleplay or demo flow, make every person practice their exact actions. People get nervous during pitches and misclick or damage demo state. If someone cannot run their part reliably, assign it to someone else.
• If it's not reliable, do not do a live demo.

Do

• App works.
• Data is correct.
• Demo state is clean.
• Physical check of how you will present, and execute the checklist right before the pitch.

Do

• Protect a 10-15 minute final buffer before the deadline, because teammates will overrun.
• When the buffer starts, force stop and pull the stable version even if people want to keep working.

Do

• Fully align with jury expectations. Criteria is secondary to preference: optimize for emotional buy-in first, then provide the logical justification.
• Give each slide one key message.
• Make each message written, visualized, and spoken.
• Otherwise they won't get it, because they're thinking about the team before, that they need to pee, how they get home, what one criteria actually means, and which team you actually are.
• Train the pitch at least 5 times for smooth delivery and consistent timing.

Do

• Use persona-based storytelling, with costumes for roleplay.
• Example: 'This is James, he's a carpenter…', show his workflow, then show how he uses your product.
• Prefer a live demo if stable, and make sure it's fully tested.
• Avoid generic product walkthroughs.

Do

• Add elements others won't have: real customer interviews, photos of calls and notes, real validation and user testing.
• Clearly define the business case: value proposition, target user, go-to-market, and pricing.
• Ensure everything makes sense logically.

Do

• Train the pitch at least 5 times for smooth delivery and consistent timing.
• Ask organizers what happens if you exceed time. If flexible, slightly exceed by design (others will, and get the advantage if you don't). If strict, train to the exact cutoff.
• Include multiple team members if possible, but do not sacrifice quality.
• Use roleplay for weaker speakers.

Do

• If you win, acknowledge the success and enjoy the moment.
• If you don't, accept the outcome.
• Be happy with your result, some you win and some you don't.
• Try again.

Do

• No matter the outcome, identify what worked.
• Identify what didn't.
• Write specific lessons for next time rather than vague takeaways.

Do

• Share publicly: LinkedIn posts and a project showcase.
• Do this regardless of outcome.
• Tag organizers, sponsors, teammates, and supporters where appropriate.

Do

• Use the exposure to build your network.
• Create opportunities.
• Continue the project if relevant.