Lesson 6

Build the proof of concept

Pick a stack you can ship today. Feed your PRD into Claude Code or Cursor as the source of truth. Iterate one feature at a time. Deploy a preview after each.

18 minFrom Product Idea to Proof of Concept

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:

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.

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

  1. Open a new directory. Paste the PRD into Claude Code (or open Cursor with the PRD as a markdown file in the workspace).
  2. Ask for the scaffold. Run it. Confirm a hello-world version is live before adding any features.
  3. Implement features in priority order. After each, deploy and click through.
  4. When something breaks, paste the error back. Don't fix what you don't understand.
  5. 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.

I want you to scaffold a proof of concept for the product described in the PRD below.

Stack: [name your stack — e.g. Next.js 16 with the App Router, deployed to Vercel]

Goal of this turn:

  • Create a fresh project in the current directory.
  • Add the dependencies needed for the POC slice (only those).
  • Build a single hello-world page that confirms the stack runs.
  • Do NOT implement any features yet. We will do those one at a time in subsequent turns.

PRD:

[paste your full PRD from Lesson 05]

Before you change anything, list the files you plan to create and ask me to confirm. Then run the project locally and tell me the URL to open.

Implement the next feature for the POC.

Feature to implement now: [name the single feature — e.g. "the user can paste a transaction CSV and see it parsed into a table"]

Constraints:

  • Only this feature. Do not start the next one.
  • Match the functional requirements in the PRD (already in context).
  • File-by-file: tell me which files you will create or modify, ask me to confirm, then make the changes.
  • After the changes, tell me how to test it locally (e.g. "visit /dashboard and paste this sample CSV").
  • If you have to make a design choice that isn't in the PRD, ask me before assuming.

Don't add error handling, logging, or validation beyond what's required to make the happy path work. We are still proving the assumption, not productionizing.

Deploy this POC as a preview I can share.

Target: [your stack's deployment target — e.g. Vercel preview deployment]

Steps:

  1. Confirm there are no uncommitted changes blocking deploy.
  2. Walk me through the minimum required setup if I haven't connected this repo to the host yet.
  3. Trigger the deployment.
  4. Give me the preview URL when it's ready.

Do not configure analytics, custom domains, or anything beyond what's needed to get a clickable URL. We'll add the rest after the user feedback comes back.

I tried the POC and hit a problem. Help me debug it.

What I did: [step-by-step what you clicked / typed]

What I expected: [the outcome the PRD says should happen]

What actually happened: [the actual outcome — paste any error messages verbatim]

Constraints on the fix:

  • Find the root cause first. Tell me what you think is happening before changing any code.
  • Make the smallest possible fix. Do not refactor adjacent code "while you're here."
  • After the fix, walk me through how to verify it.

If the root cause is "the PRD was wrong about how this should work," say so — the fix might be to update the PRD, not the code.

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.

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.

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.

🎉

You've completed this course.

Head back to explore more workshops and keep building.

Back to all courses