How to Win Hackathons
Structure your pitch:
How to Win Hackathons
Before the Hackathon
Team Formation (Most Critical)
- Ideal team: 3–4 people with DIVERSE skills
- 1 ML/Data person
- 1 Backend developer
- 1 Frontend / UI person
- 1 Presenter / product thinker (can overlap)
- Find teammates: MLH Discord, Devpost forums, university clubs, LinkedIn
- Pre-agree on: tech stack, communication tools (Discord/Slack), GitHub workflow
Pre-Hack Prep
- Set up GitHub repo template in advance
- Prepare boilerplate: FastAPI backend, React frontend, Jupyter notebook
- Study the sponsor APIs if announced early (many prizes go to "best use of X API")
- Brainstorm 5+ ideas before the hack starts — don't arrive blank
During the Hackathon
Time Allocation Formula
| Phase | Time % | What to Do |
|---|---|---|
| Ideation & Validation | 15% | Pick idea, validate it's buildable, define MVP |
| Core Development | 65% | Build the ONE core feature that matters |
| Polish & Presentation | 20% | UI cleanup, demo prep, pitch practice |
Idea Selection Criteria
- Solves a REAL pain point (not a cool tech demo)
- Has a clear target user
- Can be demoed in 2–3 minutes
- Uses at least one sponsor API (boosts prize chances)
- Something judges can understand in 30 seconds
Development Rules
- One tech stack only — no experimenting with new frameworks mid-hack
- Build MVP first — 3 features that work > 10 features that crash
- Commit often — git save your work every 30 min
- Cut scope ruthlessly — winning teams build LESS but finish it
- Mock data is fine — if the real API breaks, have fake data ready
Demo Preparation
- Script the EXACT path you'll click through
- Test 5+ times — the demo must be flawless
- Have a backup: screen recording video of it working
- Narrate while clicking: "Here the user clicks X and the AI does Y..."
The Pitch (Where Hackathons Are Won)
Structure your pitch:
- Hook (15 sec): "Every year X problem costs Y lives/dollars"
- Solution (30 sec): "We built Z — it does ABC"
- Demo (60–90 sec): Show it live
- Impact (20 sec): Who uses it, what changes
- Ask/Next steps (15 sec): What you'd do with more time
Judging Criteria — What Judges Actually Score
From interviews with 5+ Devpost hackathon judges (research-verified):
| Criterion | Weight | What Judges Actually Check |
|---|---|---|
| Creativity & Innovation | High | Genuine fresh idea — not retrofitted from a side project |
| Technical Execution | High | Code quality, robustness, implementation depth |
| Problem-Solving | High | Evidence the team thought about THIS specific problem |
| Functionality | High | "Is that finished product something I would want to use?" |
| Impact | Medium | Real-world potential, commercial or social value |
| Design & UX | Medium | Depends on competition — sometimes explicit criteria |
What Judges Say Eliminates Teams Immediately
- Not meeting the basic requirements — judges were "consistently surprised" how many teams don't. Read the criteria. Twice.
- Functional failure — slick front-end with non-functional core. Judges need to see it work.
- Unbalanced submission — excelling in one dimension but neglecting others.
- Recycled project — judges circulate. They notice when the same project appears across hackathons.
- Missing documentation — no slide deck, no code explanation, no README.
What Judges Say Wins
- Storytelling. "Judges are human and love to hear stories." Personal connection to the problem.
- Functional MVP. Core feature working > many half-built features.
- Authentic problem-solving. Evidence of genuine insight into the problem space.
- Enthusiasm. "Enthusiasm signals a lot of time, thoughtfulness, and energy."
- Future scope. Show the modular design and what comes next — judges who care about innovation want to see vision beyond the MVP.
2025 Judging Shift — What's New
Investability has replaced "technical impressiveness" as the primary lens. From Klaviyo's 2025 winning guide: "Judges are evaluating investability. A technically complex project that solves no real human problem is a failure. A simple technical solution addressing a massive, painful market need is a potential unicorn."
Quantified impact is now expected, not optional. Winning projects in 2025 consistently led with measurable outcomes: "saves 40% of time," "processes in 30 seconds," "reduces cost by X%." Vague "improves productivity" pitches lost to specific numbers.
Red flags judges specifically called out in 2025:
- Beautiful Devpost page with stock footage but no working demo — judges now check GitHub for code depth
- Resubmitted projects with minor tweaks — judges circulate across hackathons and notice
- Superficial API integration (one endpoint, trivial use case) — explicit criterion checked
- Missing code in the repository while claiming technical depth
New pattern that wins: End your pitch with the startup vision, not "future work." Judges looking for investable potential want to hear: target market + pain size + what you'd build with 3 more months.
24-Hour vs. 48-Hour Hackathon Timing
24-Hour Structure
| Time | Action |
|---|---|
| 0–2 hrs | Ideation, roles, tech stack lock-in, scope definition |
| 2–4 hrs | Architecture and setup ONLY — no scope expansion after hour 4 |
| 4–18 hrs | Execution. One feature at a time. |
| 18–22 hrs | Bug fixes, polish, demo prep |
| 22–24 hrs | Rehearsal, submission, rest |
48-Hour Structure
- Same principles but more time for research/feasibility in hours 0–6
- Lock scope at 25% of elapsed time (hour 12)
- Use the extra time for a light backend, data pipeline, or ML model
Common Winning Moves
- Apply for EVERY sponsor prize, not just the main prize — each is a separate judging pool
- Talk to mentors early — they often become your advocates with the judges
- Post on social media during the hack (some sponsors actively monitor this)
- Be the team that's enthusiastic and engaging, not just technically competent
- Prepare an offline demo backup (recorded video) — connectivity failure = eliminated
Common Losing Mistakes
- Over-engineering (building APIs for an API for an API)
- Pivoting the idea past the 25% time mark
- Neglecting the pitch/presentation — this is where most competitions are won or lost
- Building for judges instead of for users (judges can tell)
- Not sleeping (bad decisions compound exponentially in final hours)
- Expanding scope when you should be polishing the core
AI-Assisted Development (2025–2026 Meta) — The New Baseline
In 2024, using AI tools was an edge. In 2025, it is the expected baseline — every serious team uses them. The new edge is in how well you orchestrate AI tools, not whether you use them.
The "Three Hat" Framework (2025 Winning Mental Model)
Before writing a single line of code, every winning team in 2025 applied this in order:
- Investor Hat — Define the problem with business-model thinking. Use a Business Model Canvas or PRD template. What is the pain? Who has it? What is the market size? If you can't answer these, your idea isn't ready.
- Architect Hat — Design the solution at a system level before prompting any AI. What agents/modules are needed? What does data flow look like? What APIs are critical?
- Vibe Coder Hat — Rapid AI-assisted execution with the right tools for each layer.
Winners are described as "orchestrators," not coders. The best problem-framer + AI-director wins, not the fastest typist.
The 2025 Full AI Dev Stack
| Tool | Role | Speed Gain |
|---|---|---|
| Lovable (lovable.dev) | Full-stack scaffold from single prompt (auth, DB, frontend) | Zero-to-app in one prompt |
| Bolt.new | Browser-based full-stack, instant sharing, no local setup | Eliminates "works on my machine" |
| v0.dev (Vercel) | React UI from text description | Frontend compressed from 40–60% to 10–15% of time |
| Cursor (cursor.sh) | Multi-file AI-augmented IDE | 2–3x individual developer output |
| Claude Code | Complex logic, codebase reasoning, multi-file debugging | Cuts integration bugs 50–70% |
| Gemini 2.5 Pro | Reading long hackathon briefs and API docs | Handles 2M token context — reads entire briefs at once |
| Gamma (gamma.app) | Pitch deck from bullet points | 10-slide deck in < 1 minute |
| n8n | Workflow automation, 400+ API integrations | Backend logic without custom code |
| Perplexity AI | Research on APIs and SDKs during the hack | Replaces Google for technical lookup |
Winning combo: Scaffold with Lovable → refine UI with v0 → handle deep complexity with Claude Code or Cursor. Do not use all tools at once — assign the right tool to each layer.
The Per-Feature Agent Chat Workflow (Key 2025 Insight)
Open a fresh agent chat for every discrete feature. Never let a single chat accumulate context for multiple features. This is the most actionable workflow improvement from 2025 winner accounts — it creates a clean "paper trail" and maximizes useful context per feature.
Feature 1 → New chat → build → close
Feature 2 → New chat → build → close
...
Multi-Agent Architecture — The Dominant Pattern in 2025 Winners
In 2024, a strong single-model integration won. In 2025, multi-agent systems dominate every major hackathon's winner list. If your project can be described as "AI agents collaborating," you are aligned with the winning meta.
Winning 2025 hackathon projects with multi-agent patterns:
- RiskWise (Microsoft AI Agents Hackathon, $20K Best Overall): Supply chain disruption agents in real time — Python, React/Next.js, Azure AI Agent Service, Semantic Kernel
- Apollo: Multi-agent deep research with Athena + Hermes coordinator agents, self-reflective RAG, vector memory
- GameForge AI: 4 specialized agents in a LangGraph pipeline — turns a game idea into a playable browser game in 60 seconds
- Stylin': Two AI agents collaborate in real-time to identify fashion items + build 3 outfits in 30 seconds
The new archetype: Agents that are proactive teammates (observe → decide → act autonomously), not passive tools that wait for user input.
RAG Over Mock Data (2025 Upgrade)
"Mock data is fine" was the old rule. The 2025 upgrade: use real live data via RAG, even simple web scraping + a vector DB. Judges respond strongly to live, real data.
# Minimal RAG setup (under 2 hours)
# pip install firecrawl-py chromadb sentence-transformers
from firecrawl import FirecrawlApp
import chromadb
# Scrape real data
app = FirecrawlApp(api_key="your-key")
result = app.scrape_url("https://[real-data-source].com")
# Store in vector DB
client = chromadb.Client()
collection = client.create_collection("hackathon_data")
collection.add(documents=[result['content']], ids=["doc1"])
# Query at inference time
results = collection.query(query_texts=["user question here"], n_results=3)
Firecrawl + Chroma (or Pinecone/pgvector) is the most cited setup from 2025 winners — takes < 2 hours.
Using Sponsor APIs Strategically
Most hackathons have 5–10 sponsor prizes. Each is a separate judging pool with fewer competitors:
- "Best use of Twilio API" might have 8 entries vs 200 for the main prize
- Study the sponsor's developer docs BEFORE the hackathon starts
- Attend sponsor workshops — workshop hosts often become advocate judges
Depth of integration matters more than breadth. Judges in 2025 explicitly flagged "superficial API usage (calling one endpoint) is now easily spotted and penalized." Meaningful integration = custom workflow using 3+ endpoints or a non-trivial use case.
# Speed run: integrate a sponsor API in < 30 min
# Prompt: "Show me the minimal Python code to integrate [Sponsor API]
# for [specific use case]. Give me pip install, auth setup, and a
# working demo calling at least 2 endpoints."
Multi-prize approach: Apply for every applicable prize category. Each is judged separately. A single project can win 3–4 prizes at one hackathon. Many losing teams only apply to the main prize and miss 80% of available prize money.
Online/Async Hackathon Strategy (Different Rules)
Many DoraHacks, Devpost, and lablab.ai hackathons are 100% online with 2–4 week submission windows. These have different optimal strategies vs in-person:
In-person: Speed > completeness. Ship MVP fast.
Online: Polish > speed. Judges evaluate the submission package, not just a live demo.
For online hackathons:
- Take 60% to build, 40% to document, record, and present
- Submit a 3–5 minute professional demo video (judges watch this first)
- Deploy your app so judges can try it (Vercel, Railway, or Fly.io — all have free tiers)
- Submit 2–3 days early and refine based on the submission form
- Write a detailed project description with specific metrics of impact
The Pitch Deck Template (Gamma: 20 Minutes)
Prompt to Gamma (gamma.app): "Create a hackathon pitch deck for:
- Project name: [name]
- Problem: [one sentence with pain point + who has it]
- Solution: [one sentence of what we built]
- How it works: [3 steps, technical stack included]
- Demo highlights: [what judges will see]
- Impact: [quantified — saves X%, processes in Y seconds]
- Next steps: [specific startup vision, not vague 'future work']"
Judges see 20–100 projects. Pass the 30-second test: what is this, who is it for, does it work?
Resources
- Devpost Judge Interview: info.devpost.com/blog/hackathon-judging-tips
- Judging Criteria Deep Dive: info.devpost.com/blog/understanding-hackathon-submission-and-judging-criteria
- TAIKAI: 6 Judging Criteria Explained: taikai.network/en/blog/hackathon-judging
- Cursor IDE: cursor.sh
- v0.dev (Vercel UI generator): v0.dev
- Bolt.new (full-stack generator): bolt.new