`. Use `valign="top"` so columns align.
**Collapsibles.** Push long content out of the main scroll with `
...
`: the repo tree, local setup, a step-by-step call flow, a footnotes-and-sources list. When several sit together (for example multiple architecture diagrams), mark the primary one `` so it stays visible.
**Callouts.** Use GitHub alerts sparingly for the one thing that matters: `> [!NOTE]`, `> [!TIP]`, `> [!IMPORTANT]`. A common, high-value one is a "what is in this repo vs. production" note.
**Architecture diagram.** A Mermaid `flowchart` with short node labels and `classDef` color coding to group subsystems. Keep it readable at a glance; move the detailed sequence into a `` list below it.
**Section rhythm (optional).** A consistent leading glyph on every H2 gives the README an identity: an emoji per section (DispatcherAI) or one repeated bar like `▌` (AdaptEd). Choose once, then apply it throughout.
**Anchor links.** GitHub builds a heading's anchor by lowercasing it, dropping punctuation and HTML entities, and turning spaces into hyphens (so `## The Problem` becomes `#the-problem`). Use that to wire the table of contents and the jump-nav.
**Typography.** Reach for HTML entities for fine control: ` ` to keep words together, `‑` for a non-breaking hyphen (`2‑minute`), `–` for ranges (`Nov 16–17`), `·` or `·` as a separator, `→` or `↗` for "go" links, `…` for elisions, and `—` for an aside (a comma, parentheses, or a colon often reads just as cleanly). Render routes, keystrokes, and UI chips as keycaps with ``, and use `` or `` for captions.
**Team cards.** The base card is a headshot, name, role, and GitHub plus LinkedIn links in a `` cell. Variations worth borrowing from the exemplars: a one-line contribution blurb per person, a `⭐` marker on the author, the GitHub link as a badge image rather than text, rounded headshots via an inline `border-radius` style, and a `github.com/.png?size=120` avatar when no headshot file exists.
**Dark and light hero (optional).** Serve theme-aware art with `` and `prefers-color-scheme` sources.
## Write it
Produce the full `README.md`, not an outline. Match the voice of the exemplars: confident, concrete, and brief. Favor a benefit-first tagline over a feature list. In the problem section, state the stakes and one sourced number, then pivot to the build.
Start the hero from this shape and fill it with real facts:
```html
```
Keep the README a landing page. If setup runs long, collapse it. If the architecture has ten steps, show the diagram and hide the prose in ``.
## Asset handling
- Reference images by repo-relative path (`./.github/assets/hero.png`) or raw URL (`https://raw.githubusercontent.com///main/...`). Be consistent.
- Store new art in `.github/assets/`. If a needed image does not exist, insert a labeled `` placeholder instead of a link that 404s.
- Team headshots can fall back to GitHub avatars: `https://github.com/.png?size=120`.
- If the repo has its own asset or OG-image generation (for example an `opengraph-image.tsx`), offer to reuse it rather than inventing a new pipeline.
## Set the repository metadata (About)
The README is the page; the repo's "About" box is the search-and-preview layer that decides whether anyone opens the page at all. It shows under the repo name, in GitHub search results, and on the social card when the link is shared. After writing the README, set it from the same facts so the three stay consistent.
Set three fields:
- **Description**: one sentence, the tagline or a tightened version of it. Lead with what it does, not the stack, and keep it under about 120 characters so it does not truncate.
- **Website**: the live deployment URL, or the demo video link if there is no live site.
- **Topics (tags)**: five to twelve lowercase, hyphenated tags pulled from the real stack and domain, plus `hackathon` and the event or sponsor tech where relevant (for example `nextjs`, `fastapi`, `openai`, `voice-ai`, `hackathon`). GitHub allows up to twenty, each lowercase and at most fifty characters. Pick the ones a recruiter or judge would actually search, not every dependency.
Apply them with the GitHub CLI from inside the repo, since the agent can run it directly:
```bash
gh repo edit \
--description "One line on what it does, under ~120 characters" \
--homepage "https://yourapp.com" \
--add-topic nextjs,fastapi,openai,voice-ai,hackathon
```
`--add-topic` merges with any existing topics rather than replacing them; run `gh repo edit --help` to confirm the flags for the installed version. If `gh` is missing or not authenticated, do not guess credentials: fall back to the "About" gear on the repo's GitHub page and hand the user the exact description and topic list to paste. Never invent a description or a tag that misrepresents the project.
## Verify
Before finishing, check:
- Exactly one `# H1`.
- Every link resolves and every badge URL is well-formed.
- The YouTube ID in the poster matches the demo link.
- Every referenced image exists in the repo or is marked TODO.
- The Mermaid block parses (balanced brackets, valid node ids).
- The repo description, website, and topics are set and match the README, with no invented claims.
- No fabricated awards, stats, prize figures, or team details.
Preview in a Markdown renderer. Note that GitHub-only features (alerts, Mermaid, `` theming) render on GitHub but not in every previewer, so confirm on the repo when possible.
## Final output
Return:
1. **README.md**: written to the repo root (after showing a diff if one already exists).
2. **Repo metadata**: the description, website, and topics applied via `gh`, or the exact values to paste if `gh` was unavailable.
3. **Asset checklist**: which images exist and which are TODO.
4. **Facts used vs. omitted**: what was included and which sections were skipped for lack of real facts.
5. **Next steps**: for example, run `demo-prep` for the matching demo script, capture a custom poster, or pin the repo.
## Boundaries
- Never invent awards, statistics, prize amounts, ranks, or team information. Omit over guess.
- Do not overwrite an existing README without showing the change and getting a go-ahead.
- Set the repo's About metadata (description, website, topics) from the same facts, and never invent a description or tag that misrepresents the project.
- Keep it a landing page, not exhaustive documentation. Deep setup and long flows belong in ``.
- Match the repo's real stack and structure. The README describes what exists, not an aspirational version.
---
# Blog
> Hackathon strategy write-ups: how to win, pick a stack, pitch, and turn weekend projects into career wins.
Canonical: https://thehackathonplaybook.dev/blog
---
Stay up to date
## Get new hackathon guides in your inbox
Short, specific strategies on building and pitching, from 36+ hackathon wins.
[5 min readUpdated Oct 2, 2026
#### How I Fine-Tune LLMs at Hackathons on Rented Cloud GPUs
How I fine-tune LLMs at hackathons: rent an A100 or H100 on Vast.ai by the hour, then let an AI agent set up, watch, and debug the machine while you build.
Read article](https://thehackathonplaybook.dev/blog/fine-tune-llms-at-hackathons-cloud-gpu)[4 min readUpdated Sep 14, 2026
#### What to Do After a Hackathon: Ship 5 Assets That Get You Hired
My first internship came from one LinkedIn post about a hackathon we didn't win. What to do after a hackathon: five linked assets, four written by AI skills.
Read article](https://thehackathonplaybook.dev/blog/what-to-do-after-a-hackathon)[6 min readUpdated Sep 14, 2026
#### 9 Hackathon Pitch Mistakes I Saw at LA Hacks
Judging LA Hacks, I watched good projects lose points to hackathon pitch mistakes. The one almost every team made was leaving the judges no time for Q&A.
Read article](https://thehackathonplaybook.dev/blog/hackathon-pitch-mistakes-la-hacks)[5 min readUpdated Sep 14, 2026
#### How to Build with ElevenLabs and Cursor at a Hackathon
My loop for a voice AI hackathon project: write the PRD first, connect ElevenLabs to Cursor through MCP, then have the agent write each test before the feature.
Read article](https://thehackathonplaybook.dev/blog/build-with-elevenlabs-and-cursor)[3 min readUpdated Sep 14, 2026
#### Non-Coders Winning Hackathons: What Domain Experts Bring
A personal injury lawyer took 1st at Anthropic's hackathon without writing code. What that says about non-coders winning hackathons, and where coding helps.
Read article](https://thehackathonplaybook.dev/blog/non-coders-winning-hackathons)[3 min readUpdated Sep 14, 2026
#### Hackathon Pitch Guide: How to Present Your Project and Win Prizes
A hackathon pitch guide with one 3-minute structure: problem, live demo, how it works, and impact. Plus Q&A prep, and how to cut it down for a shorter slot.
Read article](https://thehackathonplaybook.dev/blog/hackathon-pitch-guide)[4 min readUpdated Sep 14, 2026
#### Hackathon Tips for Beginners: Your First Hackathon Survival Guide
You don't need an idea or a team to go to your first hackathon. These hackathon tips for beginners cover what to set up at home and how to spend the 24 hours.
Read article](https://thehackathonplaybook.dev/blog/hackathon-tips-for-beginners)[4 min readUpdated Sep 14, 2026
#### Best Tech Stack for Hackathons in 2026: Tools That Win Prizes
The best tech stack for hackathons is the one your team already knows. If you don't have one yet, this is the Next.js, FastAPI, and Supabase default I use.
Read article](https://thehackathonplaybook.dev/blog/best-tech-stack-for-hackathons)[4 min readUpdated Sep 14, 2026
#### How to Win Hackathons: A Complete Guide from 36+ Victories
How to win hackathons, in the seven phases I learned across 50+ events and 36+ wins: from picking your team to following up with people after judging ends.
Read article](https://thehackathonplaybook.dev/blog/how-to-win-hackathons)
© 2026 The Hackathon Playbook
[Got feedback? feedback@thehackathonplaybook.dev](mailto:feedback@thehackathonplaybook.dev)
---
# How I Fine-Tune LLMs at Hackathons on Rented Cloud GPUs
> How I fine-tune LLMs at hackathons: rent an A100 or H100 on Vast.ai by the hour, then let an AI agent set up, watch, and debug the machine while you build.
Canonical: https://thehackathonplaybook.dev/blog/fine-tune-llms-at-hackathons-cloud-gpu
Last updated: 2026-10-02
---
## My Laptop Doesn't Train the Model. A Rented H100 Does.
I rent the GPU.
People ask me how I fine-tune LLMs and other big models during a hackathon when their own laptops take all weekend. I don't train on my laptop. I rent an **A100 or H100 by the hour** on Vast.ai, train there, copy the weights back, and shut the machine down.
That part isn't new. What changed is who runs the machine. These days an AI agent rents it, sets it up, watches it, and fixes it when it breaks. The best proof I have isn't even a training run. It's a 4K music video an agent rendered on 11 rented GPUs, driven from one terminal on the same PC I game on.
Video: [P(doom) · Tabletop, a Blender music video rendered on rented Vast.ai GPUs](https://www.youtube.com/embed/Hu3Gupp-wKc)
*The finished video. Every scene is a Python script, rendered at 4K 60 fps on rented RTX 5090s. The song isn't mine: "I'm Upping My P(doom)" has lyrics by osmarks, built on an opening verse and chorus by MusicPerson, and this is the Suno "Claude-Pop" version posted by deckard (@slimer48484). Full credits are in the repo linked below.*
| Rented RTX 5090s | 4K Frames | Three Render Runs | Remote Desktops Opened |
| --- | --- | --- | --- |
| 11 | 9,400 | ~$18 | 0 |
*Nine of the video's 18 scenes, straight off the rented GPUs at 4K.*
## Why a Rented GPU Beats the Other Options
I considered my options. **Your laptop** is out: a fine-tune that needs hours on an H100 won't finish on a laptop before judging, and the laptop is busy training instead of running your demo. **Free notebooks** are fine for small experiments, but you don't control which GPU you get or how long the session lasts. **The big clouds** often want a GPU quota increase first, and that approval can take longer than the hackathon.
What's left is a marketplace where you rent someone else's idle GPU by the hour. That's Vast.ai. Billing is per second, so a two-hour run costs two hours.
When I wrote this, Vast's own pricing pages listed H100s at a **30-day median of about $1.33 to $1.87 an hour**. For comparison, the agent's RTX 5090s ran about $0.55 to $0.75 an hour each.
**Do:**
- Pick the exact GPU, region, and disk size
- Per-second billing, no long-term commitment
- A machine is ready in minutes, no quota request
- Everything is scriptable through a REST API
**Don't:**
- Hosts vary: some have broken drivers or slow uploads
- It's someone else's machine, so keep sensitive data off it
- A forgotten machine keeps billing
## The Agent Does the Babysitting Now
Before agents, renting a GPU meant I babysat it. SSH in, install drivers, start training, then keep checking back to see if it crashed. Now I hand an agent an API key, a budget, and a goal, and go build the frontend.
Here's what that looked like on the music video. Claude, running in a terminal on my PC, did every step through Vast's API with plain **curl** and **ssh**, no web console:
1. **Check credit, then rent** It checked the balance before every rental (the rule: spend existing credit only, never top up), then filtered offers to verified RTX 5090s with 0.98+ reliability and a fast upload link.
2. **Turn a bare VM into a work box** One idempotent setup.sh installed libraries, Blender, and the project in about two minutes per machine.
3. **Run jobs detached** Every long job started with setsid nohup, so it survived the SSH session dropping.
4. **Poll the numbers** A status script looped over the machines and printed progress and GPU load for each one.
5. **Collect, verify, destroy** Each machine was destroyed the moment its output was copied off and checked, so idle boxes didn't keep billing.
The rent call itself is short:
`PUT /asks//`:
```json
{"client_id": "me", "image": "vastai/base-image:@vastai-automatic-tag", "disk": 80,
"runtype": "ssh_direct", "env": "-e NVIDIA_DRIVER_CAPABILITIES=all"}
```
> **Rendering needs one extra flag:** That **NVIDIA_DRIVER_CAPABILITIES=all** line matters for anything that uses graphics libraries, like Blender. Without it the container never got NVIDIA's EGL and Vulkan libraries, and Blender quietly rendered on the CPU, about 20 times slower.
## Every Failure Was a Number That Stopped Moving
With no screen to look at, every problem first showed up as a number that didn't move: a GPU at 0%, a frame count stuck, a file growing too slowly. The agent polled those numbers on every machine and caught each problem within minutes.
**GPU at 0% with the job running.** That host's driver never gave Blender a GPU context. The agent destroyed it, rented a replacement, and now checks every GPU is busy a minute after starting.
**A build that "succeeded" with no output.** Blender exits 0 even when its Python script throws. The fix was to grep every log for a traceback and retry.
**A file arriving at 0.2 MB/s.** That host's upload link was just slow. Re-rendering its scene on a fast machine took 25 minutes, instead of waiting hours.
Here's the surprise. Two render workers per GPU left the GPU half idle, because each 1080p frame needed about 3 seconds of single-threaded CPU work before 1.2 seconds on the GPU. **Running five workers per GPU made the render about three times faster.** Training has the same trap: a GPU stuck well under 100% usually means the CPU side, like data loading, can't keep up.
*A quick check render: consecutive 60 fps frames at reduced size, rendered on a rented review machine and pulled back to the PC.*
The agent also checked its own work. A QA pass inspected every scene of the first 4K file, then one fix agent per scene repaired its findings, testing each fix with renders on the rented machines instead of my PC.
*The first 4K 60 fps render stuttered because the puppets were posed for 24 fps. Left: before. Right: after rebaking the poses for 60 fps.*
*A bug I reported: the black hole's lens showed the laptop's fill light as a pale panel. The fixed render keeps the screen dark behind it.*
## Paste This Prompt Into Your Agent
For a fine-tune, the job is simpler than a 9,400-frame render: one machine, one training run. Put your Vast API key in an environment variable, add a little credit, and give your agent something like this:
`agent-prompt.md`:
```markdown
My Vast.ai API key is in VAST_API_KEY. Spend only the credit already on the
account. Never add funds.
Before you start, ask me: which base model to fine-tune, where the dataset
lives, and what "done" looks like (epochs, eval metric, output format).
Then:
- Check my credit through the Vast REST API.
- Rent one verified, on-demand H100 (or A100 80GB) with reliability 0.98+.
- Attach my SSH key to the instance and confirm you can log in.
- Install what training needs, copy the dataset over, and start training
with setsid nohup so it survives a dropped connection.
- Every few minutes, check GPU utilization, the loss, and the log. If the
GPU sits at 0% for a minute, read the log and fix it or replace the box.
- When training finishes, copy the weights back, verify the files, then
DESTROY the instance and tell me the total cost.
```
**Before You Rent**
- [ ] Credit loaded, and a hard rule in the prompt about not adding more
- [ ] Your SSH public key added to the Vast account
- [ ] Dataset uploaded somewhere the machine can download it
- [ ] A tiny test run first, so a bad config fails in one minute, not one hour
- [ ] A check that the GPU is actually busy right after training starts
- [ ] A plan for where the weights go when it's done
> **Destroy it when you're done:** A forgotten machine keeps billing. Make destroying the instance the **last step of the prompt**, and check the Vast console yourself before you go to sleep.
## Spend the Saved Hours on the Demo
The real win isn't the cheaper GPU. It's that training runs in the background while you build the frontend and practice the pitch, and nobody on the team spends hour 20 watching a loss curve. All three render runs for the music video cost about $18 together. A fine-tune on one H100 for a few hours costs less than that.
[Best Tech Stack for Hackathons in 2026](https://thehackathonplaybook.dev/blog/best-tech-stack-for-hackathons): The default stack I reach for, from frontend to deployment to AI APIs.
[How to Build with ElevenLabs and Cursor](https://thehackathonplaybook.dev/blog/build-with-elevenlabs-and-cursor): My agent loop for a voice AI project: PRD first, MCP second, tests before features.
---
# What to Do After a Hackathon: Ship 5 Assets That Get You Hired
> My first internship came from one LinkedIn post about a hackathon we didn't win. What to do after a hackathon: five linked assets, four written by AI skills.
Canonical: https://thehackathonplaybook.dev/blog/what-to-do-after-a-hackathon
Last updated: 2026-09-14
---
## Ship Five Linked Assets, Win or Lose
After judging, make the project easy to find.
That means five public assets: a GitHub README, a Devpost, a YouTube demo, a portfolio page, and a LinkedIn post, linked so that whichever one someone finds leads to the rest. A private repo nobody links to can't help you, whether you won or not.
> **How I Got My First Internship:** I started doing hackathons to land an internship. At LA Hacks 2023 I spent the hackathon learning vector databases for a RAG-style chat app, and we didn't even win. I posted about it on LinkedIn anyway, and the post caught the eye of an interviewer who was building the exact same thing. The interview turned into two people geeking out over one problem, and a week later I had my first internship offer. That was within my first four hackathons. I would never have gotten that internship otherwise.
## No Asset Should Be a Dead End
You don't control where someone enters. A recruiter might land on your YouTube, a developer on your GitHub, a founder on your Devpost. A repo with no links out, or a LinkedIn post with no demo, is where they stop. So Devpost, GitHub, and YouTube link to each other and to your live site, and the portfolio and LinkedIn post point into all three:
`cross-links.txt`:
```text
Devpost ──► GitHub · YouTube · Live site
GitHub ──► Devpost · Live site · YouTube · Press
YouTube ──► Devpost · GitHub · Live site
Portfolio ──► GitHub · Devpost · YouTube
LinkedIn ──► Devpost · GitHub · YouTube
```
## A Real Example: Dispatch AI
Our Dispatch AI project won the Grand Prize at the UC Berkeley AI Hackathon 2024. These are its four links:
`dispatch-ai.txt`:
```text
Devpost devpost.com/software/dispatch-ai
Live site dispatchai.art3m1s.me
GitHub github.com/IdkwhatImD0ing/DispatchAI
YouTube youtu.be/hdpdgxrilQM
every page above links to the other three
```
## Recruiters Usually Won't Read Your Code
The recruiter who screens your resume and the person who DMs you on LinkedIn usually aren't going to read your source code. They'll watch a 90-second demo, skim a Devpost, or click a live site. If you and another candidate look the same on paper, that demo can break the tie.
> It's not enough to be good. In order to be found, you have to be findable.
>
> Austin Kleon, author of Show Your Work!, 2014
> **Some of Your Readers Are AI Tools:** More recruiters and applicant systems use AI to screen candidates. A written README, Devpost, and portfolio page, plus a captioned video, give it plenty to go on.
## Let AI Write the Four Mechanical Ones
Four of the five assets are mechanical, and AI writes them faster and more consistently than you will at 4am after your demo. So I built skills that do it.
The **ship-it skill** interviews you once, then generates the portfolio site, README, Devpost, and YouTube description in order, so all four tell the same story with the same numbers. Run it from your coding agent:
`ship-it`:
```bash
# Install the skill
npx skills add IdkwhatImD0ing/hackathonstarterkit --skill ship-it
# Then tell your agent:
# "Use the ship-it skill to create all four of my
# post-hackathon deliverables from this repo."
```
If you only need one of them, each asset has its own skill:
`one-at-a-time`:
```bash
npx skills add IdkwhatImD0ing/hackathonstarterkit --skill portfolio-builder
npx skills add IdkwhatImD0ing/hackathonstarterkit --skill readme-writer
npx skills add IdkwhatImD0ing/hackathonstarterkit --skill devpost-writer
npx skills add IdkwhatImD0ing/hackathonstarterkit --skill youtube-writer
```
> **One-Time Setup for the Portfolio:** The portfolio builder uses Anthropic's frontend-design plugin for a custom look, which takes one extra install. The post-hackathon playbook has that, plus the exact prompt for every skill.
[The Post-Hackathon Playbook and Ship-It Toolkit](https://thehackathonplaybook.dev/playbook/post-hackathon): The follow-up timeline and the copy-paste prompts for every skill above.
## What You Still Do Yourself
**Record a clean demo** when the pressure is off, and get the product on screen in the first 30 seconds. If your event lets you add the video after the deadline, record it after you submit. Some events want the link at submission, so check the rules. Then youtube-writer handles the title, description, timestamps, and links.
**Write the LinkedIn post yourself,** within 48 hours. It's the asset that puts the other four in front of people, and it reads best in your own voice. Say what you built and what you learned, tag your team and the organizers, link the Devpost, GitHub, and demo, and end with one line on what you're looking for.
[Hackathon Submission Playbook](https://thehackathonplaybook.dev/playbook/submission): Where the README and Devpost skills live, plus the demo recording setup.
[How to Win Hackathons: The Complete Guide](https://thehackathonplaybook.dev/blog/how-to-win-hackathons): The seven phases, from team formation to follow-up.
---
# 9 Hackathon Pitch Mistakes I Saw at LA Hacks
> Judging LA Hacks, I watched good projects lose points to hackathon pitch mistakes. The one almost every team made was leaving the judges no time for Q&A.
Canonical: https://thehackathonplaybook.dev/blog/hackathon-pitch-mistakes-la-hacks
Last updated: 2026-09-14
---
## What I Saw Judging LA Hacks
I judged at LA Hacks, and the teams that scored low rarely had weak projects. Their pitches made me work too hard to understand and score what they built.
In a few minutes, a judge needs to see the problem you solved, why your build is impressive, and the details their rubric rewards. The mistake almost every team made was timing: they didn't leave enough time for questions (mistake 9).
| Judging Slot | Pitch + Demo | Q&A Time | Avoidable Mistakes |
| --- | --- | --- | --- |
| 5 min | 1.5 min | 3.5 min | 9 |
*The LA Hacks judging floor in Pauley Pavilion.*
## 1. You Pitched Every Judge the Same Way
Tailor the pitch like you tailor a resume. The project stays the same, but the angle shifts based on who's scoring it.
*Tailor the depth and angle to the judge in front of you.*
**Do:**
- Ask the judge's background before going deep
- Lead with the problem, workflow, and impact for non-technical judges
- Go deeper on architecture and tradeoffs for backend judges
- Show polish, interaction, and user flow for frontend judges
**Don't:**
- Pitching backend internals to a frontend-focused judge
- Skipping impact because the judge looks technical
- Assuming the judge cares about the same details your team does
*The architecture slide from our Dispatch AI pitch. A technical judge will want this. For a non-technical one, save it for follow-up.*
## 2. You Let the Whole Team Pitch
At LA Hacks, I sat through pitches where I couldn't follow a teammate, so I burned Q&A time re-asking what they'd already covered.
Every four-person team has a strongest presenter and a weakest one, and the pitch is scored on clarity.
**Do:**
- Let the strongest communicator lead
- Have one teammate drive the demo if it smooths the flow
- Bring specialists into Q&A for deeper questions
**Don't:**
- Giving every teammate equal speaking time by default
- Switching speakers every 20 seconds
- Letting the least confident speaker explain the core value
## 3. You Pitched With No Energy
Smile. It's obvious, but teams forget it the second judging starts. A flat, monotone delivery leaves the judge to figure out what's exciting on their own.
Sound proud of what you built. It shows you care, and it makes the moments that matter easy to notice.
## 4. You Used Slides as a Script
**Never put more than 10 to 15 words on a pitch slide.** If the judge is reading, they aren't listening. Slides frame the problem, show one statistic, or hold a single idea, and then you move into the solution. In most pitches, slides should take 30 seconds max.
*Our Dispatch AI problem slide: one statistic and enough visual context to feel the pain point. The 82 percent figure comes from The Pulse of 9-1-1, the 2023 NENA and Carbyne State of the Industry Survey.*
*The solution slide summarizes the workflow, then hands off to the live demo.*
Product screenshots can frame the story, but they can't replace the demo. If a screen proves the solution works, show that flow live in the product.
## 5. You Explained Things the Judge Already Knew
A couple of teams spent around 30 seconds explaining what OpenAI Agents or ElevenLabs Agents are. If the judge has used them, that time is gone.
The fix is one question: "Are you familiar with ElevenLabs Agents?" If yes, skip the definition and go straight to how you used it. If no, give the one-sentence version and move on.
## 6. You Pitched Features Instead of the Main Flow
The judge doesn't need your landing page, auth screen, settings panel, or database schema unless one of them is central to the problem. Show the problem and the user flow that proves you solved it. Everything else goes to Q&A, Devpost, or the appendix.
1. **Problem** State the pain point in one clear sentence.
2. **Main User** Show who feels the problem and what they need.
3. **Core Flow** Demo the shortest path from problem to solved outcome.
4. **Impact** Explain why that outcome matters.
[Hackathon Pitch Guide: How to Present Your Project](https://thehackathonplaybook.dev/blog/hackathon-pitch-guide): A deeper guide on pitch structure, demo flow, and judge Q&A prep.
## 7. You Skipped the Backup Demo Video
Always record a demo video. The LA Hacks Wi-Fi was spotty, and some teams couldn't run their demo because the app or the network died. Without a backup video, I had no clear way to see what the project actually did.
*A backup video still works when the venue Wi-Fi doesn't.*
A video also covers broken APIs, browser issues, and a dying laptop. Judges revisit submissions during deliberation, too, and a clear video on your Devpost keeps the project memorable.
Recording doesn't have to eat your build hours. Code locks at submission, but the Devpost (including the YouTube link) usually stays editable after. Check your event's rules first, because some treat edits after the deadline as a violation. The submission playbook covers the timing.
Here's the demo video from our Dispatch AI project, which won the Grand Prize at the UC Berkeley AI Hackathon 2024:
Video: [Winning Berkeley AI Hackathon demo video example](https://www.youtube.com/embed/hdpdgxrilQM)
*A backup video should make the project understandable even if the live demo fails.*
And our TalkTuahBank demo from HackUTD 2024, where the project won 1st Overall:
Video: [TalkTuahBank demo video, 1st Overall at HackUTD 2024](https://www.youtube.com/embed/YsH_z1azXSA)
*The product is on screen within 30 seconds, and a real money transfer happens on camera.*
## 8. You Had No Appendix
Keep the main pitch simple and the backup material deep. When a judge asks a follow-up, pulling up a ready slide looks a lot better than improvising. That's what the appendix is for, and it stays out of the main pitch.
**Good Appendix Slides**
- [ ] Architecture diagram for technical judges
- [ ] Prompt examples for AI projects
- [ ] Research data or user evidence
- [ ] Future mockups for product direction
- [ ] Technical tradeoffs and constraints
- [ ] Extra metrics that would slow the main story
## 9. You Left No Time for Q&A
I had five minutes per team: about 1.5 minutes for pitch and demo, then 3.5 for questions. Teams rarely hit it. Some spent the entire five minutes pitching.
> When judges cannot ask questions, they cannot score what they never got to understand.
>
> Bill Zhang, LA Hacks judge and author of The Hackathon Playbook
**Q&A is where the judge fills in missing rubric information.** If a rubric category never gets answered, the judge may have to give it a low score, or a zero. Leave room for questions, even if it means cutting the demo short.
## A Checklist for Your Next Pitch
*A simple flow keeps the judge focused on the scoreable parts of your project.*
**Before You Walk Up to the Judge**
- [ ] Know the judge's role, or ask for their background
- [ ] Pick one lead speaker
- [ ] Practice the pitch with a timer
- [ ] Keep slides short and visual
- [ ] Record a backup demo video
- [ ] Prepare appendix slides for likely questions
- [ ] Plan where you'll stop so Q&A has time
[How to Win Hackathons: The Complete Guide](https://thehackathonplaybook.dev/blog/how-to-win-hackathons): The full system for team formation, ideation, execution, pitching, submission, and follow-up.
---
# How to Win Hackathons: A Complete Guide from 36+ Victories
> How to win hackathons, in the seven phases I learned across 50+ events and 36+ wins: from picking your team to following up with people after judging ends.
Canonical: https://thehackathonplaybook.dev/blog/how-to-win-hackathons
Last updated: 2026-09-14
---
## What Losing Teams Get Wrong
Winning a hackathon is a learnable skill. After 50+ hackathons and 36+ wins, the teams I've seen lose usually made one of four mistakes: an idea too big for the clock, no validation, features that never show up in the demo, or a weak pitch.
| Hackathons | Wins | In Prizes | Phase System |
| --- | --- | --- | --- |
| 50+ | 36+ | $100K+ | 7 |
## Phase 1: Build a Team With Complementary Skills
Aim for **3-4 people** who between them cover these four roles.
**Ideal Team Composition**
- [ ] Frontend developer who builds polished UIs fast
- [ ] Backend or full-stack developer for APIs and data
- [ ] Designer or UX-focused member
- [ ] Someone who's good at pitching and storytelling
> **Tip:** Solo? Arrive early for team formation. Introduce yourself by what you're good at, not your major or job title.
## Phase 2: Ideate Around the Judging Criteria
Read the judging criteria and sponsor challenges before you brainstorm, and pick a real problem you can show working in a demo. If you're going for the win, pick it before the event starts so the first hours go to validation.
Try **constraint-based ideation**: list the APIs, sponsor tools, and time you have, then brainstorm ideas that use at least 2-3 of them. Dispatch AI came from two combinations in a row. An LLM plus the Twilio API gave us an AI that answers phone calls, and pointing that at public safety made it an AI 911 dispatcher.
## Phase 3: Validate Before You Build
Before anyone writes feature code, spend **1-2 hours** on these four checks.
1. **Test Your APIs** Call every external service you plan to use. Check rate limits, auth, and data format.
2. **Scope the MVP** List the minimum features the demo needs. Cut the rest.
3. **Check for Prior Art** Search Devpost for this hackathon's past winners, and skip ideas that already won.
4. **Draw the Architecture** Sketch how the pieces connect, then split the tasks.
## Phase 4: Execute With an MVP Mindset
Build the minimum viable **demo** first: the 2-3 features you'll show judges in the pitch. My default stack for that is **Next.js, Python with FastAPI, and Supabase or Firebase**.
> **Warning:** If you're going for the win, use a stack your team already knows, and save new frameworks for a hackathon where learning is the goal.
[Best Tech Stack for Hackathons in 2026](https://thehackathonplaybook.dev/blog/best-tech-stack-for-hackathons): My default stack, and when to swap parts of it.
## Phase 5: Pitch Short and Leave Time for Questions
When I judged at LA Hacks, each team got five minutes, about 1.5 to pitch and 3.5 for questions, and some teams pitched for all five. Questions are where a judge fills in the rubric categories your pitch missed. Slot lengths vary, so ask about yours.
Open with the problem, then show **the product live** instead of on slides. Before you walk up, time at least one full run out loud and mark where you'll stop to leave room for questions.
[Hackathon Pitch Guide: Full Deep Dive](https://thehackathonplaybook.dev/blog/hackathon-pitch-guide): Pitch structure, the live demo, and judge Q&A.
## Phase 6: Polish the Devpost and Demo Video
Judges revisit submissions during deliberation, after you've left the table, so the Devpost has to explain the project without you.
**Submission Checklist**
- [ ] A project description that starts with the problem
- [ ] 60-90 second demo video with screen recording and voiceover
- [ ] Screenshots showing key features
- [ ] Architecture diagram in README
- [ ] List of technologies and APIs used
- [ ] Team member roles and contributions
Here's our TalkTuahBank demo from **HackUTD 2024, where we took 1st Overall**. It runs about two minutes, a bit over that target. Watch how early the product shows up and the $200 transfer that happens live on camera.
Video: [TalkTuahBank demo video, 1st Overall at HackUTD 2024](https://www.youtube.com/embed/YsH_z1azXSA)
[Hackathon Submission Playbook](https://thehackathonplaybook.dev/playbook/submission): Demo video examples, README templates, and the recording setup I use.
## Phase 7: Follow Up Within 48 Hours
Email the sponsors and mentors you met within 48 hours, while they still remember you. Push the code to GitHub with a real README, and post about what you built. That post is how I got my first internship: a LinkedIn post about our LA Hacks 2023 project, which didn't win.
Some projects keep going after the weekend. We won the **Grand Prize at the UC Berkeley AI Hackathon 2024** with Dispatch AI, worth about $64K across prizes: a $25K Berkeley SkyDeck Fund investment with a Golden Ticket to SkyDeck Pad-13, $25K for AI For Good, and roughly $14K of hardware for first place in Best Use of Intel AI (devpost.com/software/dispatch-ai). We kept building it, and it's now a company I co-founded.
[The Post-Hackathon Playbook](https://thehackathonplaybook.dev/playbook/post-hackathon): What to post, who to message, and when.
---
# Best Tech Stack for Hackathons in 2026: Tools That Win Prizes
> The best tech stack for hackathons is the one your team already knows. If you don't have one yet, this is the Next.js, FastAPI, and Supabase default I use.
Canonical: https://thehackathonplaybook.dev/blog/best-tech-stack-for-hackathons
Last updated: 2026-09-14
---
## The Default Stack, In One Glance
After 50+ hackathons, this is the default stack I reach for and recommend to teams I mentor.
1. **Frontend** Next.js 16 + Tailwind CSS + shadcn/ui
2. **Backend** Python FastAPI, or Next.js API routes if you want one language
3. **Database & Auth** Supabase or Firebase (both set up in under 10 minutes)
4. **Deployment** Vercel for the frontend, Railway for the backend
5. **AI** OpenAI or Claude API, plus whatever the sponsor wants
> **Use what your team knows:** If you're going for the win and your team is faster in something else, use that instead. The goal is a polished, deployed demo in 24-48 hours, and a team that writes Vue shouldn't spend those hours learning React.
## Frontend: Next.js
I default to **Next.js with React**. Each page is just a file, and server rendering is built in. For UI, shadcn/ui copies ready-made components into your project as code you can edit.
`terminal`:
```bash
npx create-next-app@latest my-hackathon-app
cd my-hackathon-app
npx shadcn@latest init
npm run dev
```
**Do:**
- Next.js + Tailwind CSS + shadcn/ui (my default)
- Vite + React for a pure single-page app
- Svelte or SvelteKit if your team already knows it
**Don't:**
- Angular: too much boilerplate for 24 hours
- Complex monorepo setups
- Learning a brand-new framework mid-event
## Backend: Python or Node, Nothing Exotic
Pick **Python (FastAPI or Flask)** or **Node.js (Express)**. Python fits AI and ML work better because of its libraries. Node makes sense when your frontend is already JavaScript and you want one language.
`main.py`:
```python
from fastapi import FastAPI
from fastapi.middleware.cors import CORSMiddleware
app = FastAPI()
app.add_middleware(CORSMiddleware, allow_origins=["*"])
@app.get("/api/health")
def health():
return {"status": "ready to hack"}
```
> **Tip:** If your backend is a few simple endpoints, serverless functions on Vercel or AWS Lambda mean no server to manage. For anything heavier, run FastAPI on Railway or Render, which both do one-click deploys.
## Database and Auth: Firebase or Supabase
Both come with sign-up and login built in. Pick between them by how you want to store data.
**Do:**
- Firebase for NoSQL and real-time features
- Supabase for PostgreSQL and SQL
- Free tiers that cover a typical hackathon
**Don't:**
- Self-hosted databases (too much setup time)
- Complex ORM configurations
- Rolling your own auth from scratch
- A database without built-in auth, if your app needs logins
All of this assumes you're there to win. If you're there to learn, a new tool can be worth the whole weekend. At LA Hacks 2023 I spent the hackathon learning vector databases for a RAG-style chat app, and we didn't win. I posted about it on LinkedIn anyway, and that post led to my first internship. The vector database knowledge also landed me a full-time job.
## AI APIs: Read the Docs Before You Arrive
Pick one model provider and make a test call to its API before you arrive. Keys and rate limits are easier to sort out at home.
| OpenAI | Anthropic | Google | Fast Inference |
| --- | --- | --- | --- |
| GPT-4o | Claude 4 | Gemini | Groq |
> **Read sponsor docs early:** If you're going for sponsor prizes, check the sponsor list and read their API docs before the event starts too.
## Deployment: Ship a Live URL
Deploy so judges can open a real URL instead of watching localhost on your laptop. It's one command.
`terminal`:
```bash
# Frontend to Vercel
npx vercel deploy
# Full-stack to Railway
railway up
```
> **Warning:** For mobile, use Expo for React Native and test on your phone with a QR code. For hardware, record a working video demo as a backup in case the live hardware fails.
## Record the Demo Video
The demo video keeps working after you leave the table: judges revisit submissions during deliberation, and recruiters can find it on YouTube. Lock the tools fast so the weekend goes to building, then put your last hours into the video.
**Do:**
- Screen Studio (Mac): what I use, with auto-zoom and cursor smoothing built in
- CanVid (Windows): the closest equivalent
- 60-90 seconds, one take is fine
- Voiceover: problem first, then product
**Don't:**
- QuickTime and built-in recorders (no zoom, no polish)
- 5-minute recordings (judges skip through them)
- Slide-only videos that never show the product
- No voiceover or captions
[Hackathon Submission Playbook](https://thehackathonplaybook.dev/playbook/submission): Demo video examples and the recording setup I use.
---
# Hackathon Tips for Beginners: Your First Hackathon Survival Guide
> You don't need an idea or a team to go to your first hackathon. These hackathon tips for beginners cover what to set up at home and how to spend the 24 hours.
Canonical: https://thehackathonplaybook.dev/blog/hackathon-tips-for-beginners
Last updated: 2026-09-14
---
## If you want to place, read the judging criteria first
Judges score on a published rubric, so read it before you write a line of code. **A simple project that hits every item on it can beat a cooler one that doesn't.**
You don't need an idea or a team just to show up and get something out of it, though. You can find both at the event.
> **You belong here:** Events like HackMIT, HackUTD, and CalHacks run beginner tracks, mentoring, and workshops for people at their first hackathon.
## Set up before you arrive
Do your setup at home so the event hours go to building. Sponsors and challenges usually drop 1-2 weeks early, so you'll have time to research them too.
**Pre-hackathon checklist**
- [ ] Install your IDE (VS Code or Cursor)
- [ ] Install Git, Node.js, and Python
- [ ] Create GitHub and Vercel accounts
- [ ] Sign up on the hackathon platform (usually Devpost)
- [ ] Deploy a basic "Hello World" to test the pipeline
- [ ] Research sponsors, prizes, and challenges
- [ ] Read the judging criteria
- [ ] Join the hackathon Discord or Slack
## Find a team that covers the gaps
No team yet? Join the Discord or Slack and find the **#team-formation** channel. Post an intro with your skills (basic is fine), and message people instead of waiting to be found.
**Do:**
- Diverse skills: frontend, backend, design, pitch
- 2-4 members total
- At least one confident presenter
- People you communicate well with
**Don't:**
- Four frontend developers
- More than 4 people (coordination drag)
- Nobody willing to present
- Friends picked over skill diversity
> **Tip:** If you don't code, lead with your domain expertise and own the pitch.
[Can non-coders actually win hackathons?](https://thehackathonplaybook.dev/blog/non-coders-winning-hackathons): How to be useful on a team without writing code.
## Build small, and plan the clock
Aim for achievable but impressive: something familiar with one twist. Our TalkTuahBank project at HackUTD 2024 was banking over a plain phone call, so it works for people with no internet or smartphone. If you want a sponsor's prize, use their API too.
1. **Hours 0-2: Setup and plan** Scaffold the project with basic routing, then split up the tasks.
2. **Hours 2-8: Core build** Build the 2-3 features your demo depends on, and nothing else yet.
3. **Hours 8-12: Sleep and polish** Rest. Then clean the UI and fix rough edges.
4. **Hours 12-20: Integrate and prep** Connect the pieces, write the pitch, record a backup demo.
5. **Hours 20-24: Submit and rehearse** Finish the Devpost writeup and submit early. Then practice the pitch.
> **Take the sleep block:** Rest in hours 8-12 instead of pushing through. The last 12 hours go to integration and the pitch, and you'll want a clear head for both.
## Mistakes that cost first-timers the win
**Watch for these**
- [ ] Ideating before reading the judging criteria
- [ ] Spending more than 30 minutes on one bug
- [ ] Not asking mentors for help early
- [ ] Skipping the backup demo video
- [ ] Submitting late (often a disqualification)
- [ ] Trying to build too many features
> **Tip:** At the 30-minute mark, ask a mentor. If there's no quick workaround, cut the feature.
Record **the backup demo video**. A 60-90 second screen recording with voiceover lets judges understand your project even if the live demo dies on stage. The clip below is SoundSearch, a solo first-place accessibility tool from the AIATL hackathon that guides users through complex websites with real-time voice over a phone call. After the event, that recording reached a recruiter and turned into an internship offer.
Video: [SoundSearch demo video, solo 1st place at AIATL, that led to an internship offer](https://www.youtube.com/embed/RgH-i9SYj-o?start=22)
> **Tip:** At some events the deadline freezes your code but not the Devpost entry, so you can record the video after you submit. Check the rules first: some events count any edit after the deadline as a violation, or need the video link to submit.
[Hackathon Submission Playbook](https://thehackathonplaybook.dev/playbook/submission): Demo video examples, README templates, and the recording setup I use.
## Win or lose, walk away with more
I started doing hackathons to land an internship. My first internship came from LA Hacks 2023, where I spent the weekend learning vector databases for a RAG-style chat app and we didn't win. I posted about it on LinkedIn anyway, and an interviewer who was building the exact same thing saw it. A week later I had the offer.
1. **During** Go to the workshops, and talk to other teams and the mentors.
2. **After** Push the project to GitHub and your portfolio, even unfinished.
3. **Share it** Post your story on LinkedIn or Twitter.
If you don't place, go to another one. The UC Berkeley AI Hackathon 2023 fell on my UCSC graduation day, and I went anyway. I drove about an hour to get there, left midway through for a ceremony that ran about four hours, and ended up driving roughly four hours that day. That's how dedicated I was to hackathons back then. I didn't win anything. A year later, we won the Grand Prize there with Dispatch AI.
> **Win:** Finishing one project is a fine goal for a first hackathon.
[How to Win Hackathons: The Complete Guide](https://thehackathonplaybook.dev/blog/how-to-win-hackathons): When you're ready to compete, the full 7-phase system.
---
# Hackathon Pitch Guide: How to Present Your Project and Win Prizes
> A hackathon pitch guide with one 3-minute structure: problem, live demo, how it works, and impact. Plus Q&A prep, and how to cut it down for a shorter slot.
Canonical: https://thehackathonplaybook.dev/blog/hackathon-pitch-guide
Last updated: 2026-09-14
---
## A 3-Minute Pitch Structure
I've watched technically weaker projects win because their pitch was better. This is the structure I use. It runs about three minutes, and you can drop your project into it tonight.
1. **Problem (30 seconds)** State the pain point before you say anything about your product.
2. **Solution demo (90 seconds)** Show the product live and walk through it as a user would. Lead with your most impressive feature, not the login screen.
3. **How it works (30 seconds)** High level only. 'We use Claude's API to analyze medical records in real time.' Stop there.
4. **Impact and what's next (30 seconds)** Who it helps, and what you'd build with more time.
## Fit the Structure to Your Slot
When I judged at LA Hacks, each team had five minutes, and about 3.5 of those were for questions, which is where a judge fills in the rubric. Some teams pitched for all five. Formats vary, so ask how long your slot is and how much of it is Q&A. If Q&A comes out of the same slot, shrink this structure to about 90 seconds and keep the same order.
[9 Hackathon Pitch Mistakes I Saw at LA Hacks](https://thehackathonplaybook.dev/blog/hackathon-pitch-mistakes-la-hacks): What I saw from the judging table.
## Open With the Problem
A winning team I watched opened with this: **240 million 911 calls** are made in the US every year, and dispatchers prioritize them by hand while people are dying on the line. (That number is the National Emergency Number Association's estimate: nena.org/page/911statistics.)
**Do:**
- Lead with one statistic that shows the scale
- Open with a personal story
- Describe the problem so the judge can picture it
**Don't:**
- Opening with your team name
- Starting with your tech stack
- A long backstory before the point
- Jumping straight to the solution
## Demo Live, and Always Record a Backup
Demo live whenever you can. Slides are backup only.
> **Warning:** Pre-load realistic data: believable numbers in the dashboard and a real example to process. Never 'test123' or 'lorem ipsum'.
The Wi-Fi at LA Hacks was spotty while I was judging, and some teams couldn't run their demo at all. Without a backup video, I couldn't see what those projects did. A recording also stays on your Devpost for deliberation.
Here's our TalkTuahBank demo from HackUTD 2024, where we took 1st Overall. The problem gets one statistic and five seconds, and the product is running by 0:14. At 1:20, a $200 transfer goes through on camera.
Video: [TalkTuahBank demo video, 1st Overall at HackUTD 2024](https://www.youtube.com/embed/YsH_z1azXSA)
[More demo video examples](https://thehackathonplaybook.dev/playbook/pitching): The TalkTuahBank and SoundSearch demos, broken down.
## Win the Q&A by Naming Your Limits
**Prepare answers for**
- [ ] How does it scale?
- [ ] What's the business model?
- [ ] What were the technical challenges?
- [ ] How is this different from existing solutions?
- [ ] What would you build next with more time?
> **Tip:** When a judge asks what's missing, answer honestly instead of overselling. Something like: 'In a production version we'd add X, but for this demo we focused on Y because it best shows our core value.'
## Delivery: One Speaker, No Apologies
Have one person talk while another drives the demo, and don't switch speakers mid-pitch. Look at the judges instead of your screen, and keep a measured pace even when you're nervous. Run the whole thing out loud with a timer at least once before you walk up.
> **Don't apologize in the pitch:** Don't bring up bugs or say 'we ran out of time.' Judges don't know your original plan, so they can only judge what you show them.
[How to Win Hackathons: The Complete Guide](https://thehackathonplaybook.dev/blog/how-to-win-hackathons): All seven phases, from team formation to follow-up.
---
# Non-Coders Winning Hackathons: What Domain Experts Bring
> A personal injury lawyer took 1st at Anthropic's hackathon without writing code. What that says about non-coders winning hackathons, and where coding helps.
Canonical: https://thehackathonplaybook.dev/blog/non-coders-winning-hackathons
Last updated: 2026-09-14
---
## A Lawyer Won Anthropic's Hackathon Without Writing Code
Mike Brown, a personal injury lawyer, took 1st place at **Anthropic's Built with Opus 4.6 hackathon**, a global virtual event held February 10 to 16, 2026. Co-host Cerebral Valley puts the applicant count at 13,000. According to Anthropic's winners post, 500 were selected and only 1 of the 5 winners was a professional developer. In the same post, **Brown says he didn't write a single line of code, or even read one.**
His project, **CrossBeam**, reads California ADU building-permit plan sets and correction letters, cross-references city and state code, and returns an action plan in about 20 minutes instead of weeks. He built it with Claude Code, drawing on years of legal experience.
## Two More Non-Coders Who Won
Nina Kolari, a non-technical entrepreneur who learned iOS development with AI tools, built **Aphasio**, an iPhone communication app for people with aphasia, in **3 hours** and beat 27 other teams at the Cursor hackathon in Chiang Mai (her write-up on ninakolari.com, December 2025).
Rene Turcios, a self-described 'vibe coder' who doesn't know how to code, has competed in **200+ hackathons** since 2023 and keeps winning prizes (The San Francisco Standard, July 2025).
These three show that AI coding tools like Cursor, Claude Code, and ChatGPT can get someone who knows a problem well to a working prototype. They aren't enough to say non-coders usually beat developers.
## What Domain Experts Bring
Judges reward projects that solve a real problem, and a lawyer or a doctor starts out knowing which problems in their field are real. Kolari's write-up says much the same about her win: she built something simple that solved a specific, painful problem, and the judges responded to clarity.
Dr. Michal Nedoszytko, who placed 3rd at the Anthropic event, is a different case. Anthropic describes him as a cardiologist who had spent 20 years building healthcare software alongside his practice, and he built PostVisit.ai in 7 days. He scopes his own claim:
> Currently, you don't have to know programming to create solutions, or at least prototypes of solutions, for something that you can use personally.
>
> Dr. Michal Nedoszytko, interventional cardiologist and creator of PostVisit.ai, 3rd place at Anthropic's Built with Opus 4.6 hackathon (ReachMD, The Convergence, 2026)
So coding skill still helps. If you don't have it, compete on what you know.
**Do:**
- Win on the problem and the user experience
- Pick one specific problem and keep the build simple
**Don't:**
- Competing on technical complexity
- Copying what developer teams build
- Padding it with extra features
## The Tools: Cursor and Claude Code
**Cursor** is an AI code editor, and **Claude Code**, which Brown used, is Anthropic's AI coding assistant. In both, you describe what you want in plain English and the AI writes the code. People call this **vibe coding**.
1. **Describe it** Say what to build. Be specific about the problem and what the user sees.
2. **Try it** Use what it made. You don't have to read the code to check that it works.
3. **Say what to change** 'Make the button bigger,' 'add a loading state,' 'fix the mobile layout.'
4. **Deploy** Ship it with one command when it's ready.
> **Two Things to Do Yourself:** Keep API keys (the passwords your app uses to reach services like OpenAI) out of your code and off GitHub: put them in a .env.local file yourself, not in the chat. And before you share the link, open the live site and try it the way a judge would.
## Your First Hackathon, Step by Step
**Run this before your first event**
- [ ] Install Cursor and build one tiny app by describing it in plain English
- [ ] Pick a problem from your own field that software could fix
- [ ] Find a hackathon with a beginner track and mentors
- [ ] Lead your pitch with the problem and your expertise, not the tech
[Non-Coder Hackathon Section](https://thehackathonplaybook.dev/non-coders): Installable AI skills, setup guides, and strategies for professionals who don't code.
[Hackathon Tips for Beginners](https://thehackathonplaybook.dev/blog/hackathon-tips-for-beginners): Everything you need for your first hackathon, from prep to pitch.
---
# How to Build with ElevenLabs and Cursor at a Hackathon
> My loop for a voice AI hackathon project: write the PRD first, connect ElevenLabs to Cursor through MCP, then have the agent write each test before the feature.
Canonical: https://thehackathonplaybook.dev/blog/build-with-elevenlabs-and-cursor
Last updated: 2026-09-14
---
## Make Your Demo Talk Back
This is the loop I run to add a voice to a hackathon project. ElevenLabs generates the speech, and Cursor's agent writes the code around it. I write a spec, connect the agent to ElevenLabs, then let it build and test one feature at a time while I babysit the spend.
| Flash Latency | Languages | Free Chars/mo | Free for MLH |
| --- | --- | --- | --- |
| ~75ms | 70+ | 10K | 3 mo |
## Step 0: Write the PRD Before Cursor Opens a File
The agent writes the code, but it can't guess what you want. Before Cursor touches a file, write down what you're building, who it's for, and what done looks like. Save it as **PRD.md** and **AGENTS.md** at the repo root so every prompt reads from the same source.
1. **Run the domain-to-spec skill** It interviews you about your profession and goal, then writes AGENTS.md and PRD.md to the repo root.
2. **List routes and components** Under PRD.md > Frontend Pages and Backend Routes, name every screen and endpoint the agent should scaffold.
3. **Define done** Add an Acceptance Criteria section listing the exact behaviors a working demo must have. It becomes your test plan.
Skip the PRD and the agent keeps reinventing your data model and adding features you never asked for, burning API credits on every wrong guess. With it, the agent can type the CRUD endpoints while you decide what the interface looks like and whether the output is any good. Spend the hours you save on UX polish and the pitch.
## Step 1: Check for an MCP First
An **MCP (Model Context Protocol) server** gives your agent a menu of typed tools for a service. Instead of reading pasted docs, the agent sees real actions like 'generate speech' or 'clone a voice' and gets structured data back.
ElevenLabs ships an official one at github.com/elevenlabs/elevenlabs-mcp. Add this to Cursor's MCP config and the agent can call text-to-speech, voice cloning, sound effects, transcription, and the ElevenAgents platform directly.
`~/.cursor/mcp.json`:
```json
{
"mcpServers": {
"ElevenLabs": {
"command": "uvx",
"args": ["elevenlabs-mcp"],
"env": {
"ELEVENLABS_API_KEY": ""
}
}
}
}
```
## Step 2: No MCP? Paste the Docs URL
Some tools don't have an MCP server yet. For those, put a link to the official docs inside the prompt. Cursor fetches the page and works from the live API instead of the stale version the model remembers from training.
Here's the shape of a prompt I use to build a streaming text-to-speech endpoint without the MCP. The **'Done when' section** tells Cursor when to stop, so it doesn't wander off.
`cursor-prompt.md`:
```markdown
Read https://elevenlabs.io/docs/overview/intro and PRD.md > Backend Routes.
Create app/api/speak/route.ts in Next.js 15 (App Router, TypeScript).
Behavior:
- POST handler, accepts { text: string } JSON body
- Calls ElevenLabs text-to-speech with model_id "eleven_flash_v2_5"
- Voice ID and API key come from process.env (already in .env.local)
- Returns audio as a streaming audio/mpeg response
Constraints:
- Use the official @elevenlabs/elevenlabs-js SDK (install if needed)
- No retries, no caching, no logging
- Do not touch any other route or component
Done when:
- curl -X POST localhost:3000/api/speak -d '{"text":"hello"}' returns audio bytes
- The response Content-Type is audio/mpeg
- npm run build passes with no new TS errors
```
## Step 3: Key In, Then Build and Test
Put your API key in **.env.local** at the project root, and keep that file out of git. Your app code reads the key from there. The MCP server gets its copy from the env block in mcp.json above.
`.env.local`:
```bash
ELEVENLABS_API_KEY=sk_your_key_here
ELEVENLABS_VOICE_ID=JBFqnCBsd6RMkjVDRZzb
ELEVENLABS_MODEL_ID=eleven_flash_v2_5
```
Now hand the agent one clean task: read the PRD, build the next unfinished feature, run the test, and stop only when it passes. You watch the loop and step in when it goes sideways.
**Do:**
- Reference PRD.md and AGENTS.md
- Ask for one feature per prompt
- Name the model (eleven_flash_v2_5 for real-time)
- Say which test has to pass
**Don't:**
- 'Just build the voice feature' (no model, no test)
- Skipping the test to save time
## Make the Agent Write the Test First
The most useful habit I've found: the agent writes the **test first**, then builds the feature that makes it pass. That's test-driven development (en.wikipedia.org/wiki/Test-driven_development) with an LLM writing the code.
1. **Red** Have the agent read PRD.md > Acceptance Criteria and generate a failing test for the next feature. Run it. Confirm it fails for the right reason.
2. **Green** Have the agent write the minimum code that makes the test pass. Run it. Iterate until green.
3. **Refactor** Have the agent clean up that code without breaking the test. Run it once more to be sure.
> Write new code only if you first have a failing automated test.
>
> Kent Beck, creator of Extreme Programming, Test-Driven Development: By Example (Addison-Wesley, 2002)
A test gives the agent a hard pass/fail signal, so it converges instead of guessing. You also end up with a regression suite, which matters when you swap voices or models five minutes before the demo.
## Babysit the Spend, Then Ship
An agent in a tight loop spends real money on your Cursor subscription and your ElevenLabs credits. Runaway retries, endless tool calls, or the same audio regenerated over and over can burn through a free tier, so don't walk away from it at hour 18.
**Pre-Flight Before the Agent Loop**
- [ ] PRD.md and AGENTS.md saved at the repo root
- [ ] ElevenLabs MCP installed (or docs URL ready to paste)
- [ ] API key in .env.local, not committed to git
- [ ] Acceptance criteria written for the next feature
- [ ] ElevenLabs usage dashboard open in a tab
- [ ] Cursor agent chat visible at all times
When you pitch it, don't spend your slot explaining the tools. When I judged LA Hacks, a couple of teams spent around 30 seconds explaining what OpenAI Agents or ElevenLabs Agents are. If the judge has used them, that time is gone, so ask whether they're familiar with ElevenLabs before you explain it.
[Non-Coders Winning Hackathons](https://thehackathonplaybook.dev/blog/non-coders-winning-hackathons): How a lawyer won Anthropic's hackathon without writing code, and what domain experts bring.
[Best Tech Stack for Hackathons in 2026](https://thehackathonplaybook.dev/blog/best-tech-stack-for-hackathons): The default stack I reach for, from frontend to deployment to AI APIs.
![[TECH]](https://img.shields.io/badge/[TECH]-[COLOR]?style=for-the-badge&logo=[LOGO]&logoColor=white){kind=icon}
- Group badges by "Frontend built with:" and "Backend built with:" with 
```
If `maxresdefault.jpg` is missing for that video, fall back to `hqdefault.jpg`, or ship a custom poster in `.github/assets/`.
**Layout.** GitHub Markdown has no grid, so use HTML `
# Project Name
### One-line tagline that names the stakes.
