Next.js + Vercel
The default for most web POCs. npx create-next-app, push to GitHub, connect Vercel, you have a live URL in 15 minutes. Best when the slice involves any custom UI plus a backend.
The thin-slice principle, restated
You are about to write code. Before you do, remember what you’re building. Not the v1. Not the polished thing. The thinnest end-to-end path from Lesson 04 — the slice that proves your risky assumption. If you find yourself adding a setting, a second screen, or a “while I’m here” feature, stop. Those are the moves that turn a one-week POC into a four-month half-product.
Polish in the POC is the enemy of learning. Ship rough. Learn first.
Pick a stack you can ship today
Don’t pick the stack you’d use for v1. Pick the one where you can have a working URL in front of a real user before lunch tomorrow. Some honest options:
A single HTML file
Underrated. If your slice is “a user pastes input X, sees output Y,” one HTML file with vanilla JS and a fetch to an LLM API is faster than any framework. Host on Vercel, Netlify, or a $0 GitHub Pages.
Replit, v0, or Bolt
For visual-first POCs where you want to iterate on the UI in a browser without local tooling. Trade some control for zero-setup time.
A Notion / Airtable + a form
If the risky assumption is “will users do the manual thing,” you don’t need code at all. A form that hits a Zapier that writes to a sheet, with you doing the work behind it, is a perfectly good POC. (See: “concierge MVP.”)
The right stack is the one that gets the user in front of the slice fastest. Optimize for that, not for what you’d build if you had three months.
Claude Code or Cursor as your pair
You wrote a PRD in Lesson 05. That document is now the source of truth for the build. Both Claude Code (terminal) and Cursor (editor) work the same way: paste the PRD into context, then ask for one feature at a time. Don’t ask the AI to build the whole POC in one shot — it will, badly. Ask it to scaffold, then implement feature 1, then implement feature 2.
A working loop
- Open a new directory. Paste the PRD into Claude Code (or open Cursor with the PRD as a markdown file in the workspace).
- Ask for the scaffold. Run it. Confirm a hello-world version is live before adding any features.
- Implement features in priority order. After each, deploy and click through.
- When something breaks, paste the error back. Don’t fix what you don’t understand.
- Stop when the slice works end-to-end. Show it to a real user.
Four prompts that cover most POCs
These are the prompts you’ll actually paste. Treat them as starting points — the more specific you make them with your PRD, the better the output.
When to stop
Stop when the POC slice works end-to-end. Not when it’s polished. Not when there’s a sign-up screen. End-to-end means a real person, who is not you, can do the one thing the slice was built to test, and then you can answer the question: did the risky assumption hold?
If yes — you have a real product worth building. Go to v1.
If no — you have learned something cheap. Go back to Lesson 01 of Workshop 1, with new information.
Operator story · Lesson 6
From Alon’s notebook
The POC Alon shipped in a weekend with Claude Code — the stack he picked, the four prompts he actually used, and the moment he realized the assumption was wrong but in a useful way. Suggested hook: the specific feature he was about to add when he caught himself, and the question that made him stop instead.
[OPERATOR STORY — Lesson 12]Final assignment
Pick your stack. Run the scaffold prompt. Then the “implement one feature” prompt, once per feature in your slice. Then the deploy prompt. When you have a URL, share it with one real user. Drop the stack, the repo URL, the deploy URL, and a few notes into the workbook below.
You finished the workshop. Go find out if you were right.
Assignment · Section 12
Ship the proof of concept
Sign in to save your answers.Stack, repo, deploy URL, and what you learned.
Done with this section? Review all your answers in one place.
Review my workbook →