Founder resources · The Prototyping Guide

From your PRD to a tested prototype.

You built your PRD earlier today. This guide takes it the rest of the way: spec your build, then walk a single development cycle — front end, to a working web app, to real data, to production-grade code — and stop the moment your prototype can answer your hypothesis.

Vibe coding AI rapid prototyping Engineering-grade

Today you are in the middle stage. Fast, structured, testable — not yet production. Knowing that sets the right expectations for what you build and what comes later.

Part one

Spec your build

A spec doc is a short, plain-language file that tells your AI builder exactly what to make. The rule is simple: if a decision is not in your spec, the AI invents it — and you rarely like what it invents. Six docs cover everything. You do not need all six to start.

PRD.MD

Product Requirements Document

Required Every stage

The single source of truth for what you are building and why. Every AI builder reads this first. You already wrote it this morning — this is the doc the whole cycle runs on. The most important line is the hypothesis sentence in Section 5; if it is weak, everything downstream is too.

How: open the template, find "Ask the LLM," and paste prompts 1–6 into Claude, ChatGPT, or Gemini one at a time.

Template

TECH_STACK.MD

Technology Stack

Required Every stage

Tells the builder exactly which tools, services, and structure to use. Skip it and you may get a random framework on the first attempt and lose an hour undoing it. It also names where you stop on the cycle, which is why it pins your whole build down.

How: use the "Which lane am I in" table to get your default stack, then paste prompts 1–2 to confirm and fill gaps.

Template

UI.MD

Screen Layout & Flow

Recommended Stage 01

Describes your screens and how a user moves through them. Founder-written — you know your user, the AI does not. Pays off the moment you have more than two or three screens, and feeds straight into the front-end stage of the cycle.

How: start from your PRD's one flow (Section 5), then paste prompts 1–2 to turn it into a screen inventory and rough wireframes.

Template

DESIGN.MD

Design System

Tool-generated Stage 01

Your product's visual language — colors, type, spacing, components. You do not write this from scratch. Claude Design or Stitch generates it from a short brief; you review, adjust a token or two, and pass it to your builder so every screen looks like one product.

How: follow "How to generate this" in the template, then paste the tool's output into the file.

Template

DATA.MD

Database Schema

Optional Stage 03

Your tables, fields, and access rules. Gives the AI a precise target instead of letting it guess your data model. You only need it once your build remembers things — the backend stage of the cycle. Skip it for a frontend-only prototype.

How: paste prompt 1 to extract your tables from the PRD, then prompt 2 to fill each table's fields.

Template

API.MD

API Design Document

Optional Stage 04

The endpoints your backend exposes, the data in and out, and how errors are handled. Reach for it once you are in a real coding agent with a backend beyond basic create-read-update-delete — the production-grade stage of the cycle.

How: paste your PRD into prompt 1 to draft the endpoint list, then prompts 2–5 for contracts, auth, and error conventions.

Template

Part two

The development cycle

Here is the move most founders miss: you do not pick one tool and commit. These four stages are one continuous path — the same product growing from a look, to a working app, to real saved data, to production-grade code. Walk as far as your hypothesis needs, then stop. Two of the handoffs are smooth and one is manual — we tell you which, so nothing surprises you.

01 Front end Stitch · Claude Design
→
02 Full web app Google AI Studio
→
03 Backend Supabase · Firebase
→
04 Production-grade Claude Code · Codex

Front end — make it look real

A good-looking, clickable version of your key screens. No real data yet — just the look and the flow a user walks.

Build it with

Specs UI.MD · DESIGN.MD

Stitch Prototype builder

Google Labs' free AI-native UI tool — describe your app and get multi-screen prototypes, a design system, and exportable code in minutes.

Turns text prompts, sketches, screenshots, or voice into editable screens and front-end code, powered by Gemini. Runs entirely in the browser and exports to HTML/CSS, Figma, or straight into Google AI Studio. Frontend only — no backend, database, or deploy.

Best for Communicating an app concept visually, without Figma skills or a designer on call.

Visit Stitch Founder guide

Claude Design Design system

Anthropic's prompt-to-prototype design tool — describe what you need, get a working visual in seconds, refine through conversation.

A dual-pane workspace (chat + live canvas) that auto-generates a brand-consistent design system — colors, type, spacing, components — and applies it across every project. Exports to PDF, PPTX, HTML, or a shareable URL, and hands off directly to Claude Code.

Best for Polished, brand-consistent prototypes and decks, fast — without touching Figma.

Visit Claude Design Founder guide

Generate your screens. In Stitch, paste your PRD's core flow and your UI.MD screen list and let it draft the screens. Drop in a reference image if you want to steer the look.
Give it a visual system. Use Claude Design — or plain Claude Artifacts on the free tier — to produce your DESIGN.MD: colors, type, spacing, components. Feed that back into Stitch so every screen is one consistent product.
Click through and refine. Iterate in the tool until the whole flow feels right end to end.
Export the code. Copy Stitch's generated front-end code, or drop the design into Figma if a designer will refine it first. You carry this into Stage 2.

Done when you can click through your main flow and it looks like a real product.

Stop here → the Frontend-only version — a clickable demo or landing page to test interest.

Full web app — make it work

Turn the static front end into a working web app — forms that submit, buttons that act, logic that runs.

Build it with

Specs PRD.MD · TECH_STACK.MD

Google AI Studio App builder

Google's free browser platform for prompting, prototyping, and shipping apps powered by Gemini — no cloud account to start.

The cycle's spine. Build mode vibe-codes a full-stack app — a React front end and a Node server — auto-provisions a Firebase backend, and one-click deploys to Cloud Run. A 1M-token context window lets it hold your whole codebase at once. The interface is always free.

Best for The fastest path from idea to a deployed, AI-powered web app in the Google ecosystem.

Open Build mode Founder guide

Lovable App builder · alternative

Describe your app in plain English — Lovable builds the full stack, deploys it, and gives you the code.

Generates a React + TypeScript front end with a Supabase backend, auth, and database, then deploys to a live URL — all in the browser. Two-way GitHub sync means you own the code, and Plan Mode previews the build before it commits. Web apps only.

Best for Going from idea to a deployed web-app MVP without a developer.

Visit Lovable Founder guide

Open Build mode. Go to aistudio.google.com/apps → Build. It scaffolds a full app — a React front end and a Node server — with your Gemini API key wired in server-side automatically.
Bring your front end in — this seam is manual. There is no one-click import from Stitch. Either paste your Stitch code into the build prompt ("here is my UI, build the app around it"), or screenshot your screens and drop the images in — Build mode reads images as design reference. Give it your PRD.MD and TECH_STACK.MD as context.
Wire up the behavior. Describe the interactions in plain language. Preview the app live in the browser and keep prompting until the core flow runs.
Ship a shareable URL. Use Build mode's one-click deploy to Google Cloud Run — pick your Google Cloud project and you get a public link. Previewing is free; a deployed app and paid Gemini models can incur usage cost.

Done when a real person can open the URL and complete your core flow.

Stop here → the Full web app version — a working app that needs no accounts or saved data.

Backend — make it remember

Add accounts and data that persists — between visits, and across different users.

Build it with — pick one

Specs DATA.MD

Firebase Database · Auth · fastest

Google's app backend — a Firestore database plus Authentication, provisioned for you with zero setup.

When you build in Google AI Studio's Build mode, Firebase is wired in automatically: a NoSQL Firestore database, user sign-in, and security rules, with no separate dashboard to configure. The quickest way to add accounts and saved data when your data model is simple.

Best for Adding accounts and persistence without ever leaving AI Studio.

Visit Firebase

Supabase Database · Auth · portable

Build in a weekend, scale to millions — Postgres database, auth, file storage, and realtime in one open-source platform.

Every project gets a real PostgreSQL database with built-in auth (email, OAuth, magic links), file storage, and auto-generated APIs. Row Level Security enforces access at the database layer, and its MCP server connects coding agents like Claude Code straight to your data. Open source and self-hostable.

Best for A production-grade, portable backend you can keep and grow — especially if you'll move into Claude Code.

Visit Supabase Founder guide

Write DATA.MD first. List your tables and fields. This is the precise target your builder needs — without it, the AI guesses your data model and you pay for it later.
Pick a backend. Built-in — Firebase (fastest) Staying in AI Studio, Build mode auto-provisions a Firestore database plus Firebase Authentication with zero setup. Reach for it when your data is simple and you want no config. Supabase (portable) A real Postgres database you can keep and grow. Create a free project, grab your keys, and have your builder connect to it — the right call if you'll move into Claude Code later.
Wire it up. Prompt your builder to create the tables from DATA.MD, add sign-up and log-in, and save and load real records.
Test with two accounts. Confirm each account sees only its own data and that it survives a sign-out and a refresh.

Guardrail Even with a real backend, store no permanently-stored sensitive PII and handle no real payments.

Done when you sign out, come back, and your data is still there.

Stop here → the App + backend version — real accounts and real saved data.

Production-grade — own the code

Move the whole codebase into a real coding agent to refine, extend, fix, and prepare for real users. This is the bridge to engineering-grade.

Build it with

Specs All six

Claude Code CLI agent

Anthropic's terminal-first coding agent — reads your whole codebase, edits files, runs commands, and ships commits and PRs with your approval.

Runs in your terminal, IDE, desktop app, or browser. Makes coordinated multi-file edits, runs tests and shell commands, and handles full Git workflows. Extensible with Skills, hooks, sub-agents, MCP, and a CLAUDE.md project memory — and leads the field on real-world coding tasks.

Best for Taking a working prototype into real, reviewable, production-grade code.

Visit Claude Code Founder guide

OpenAI Codex CLI agent · alternative

OpenAI's coding agent — terminal, desktop app, IDE, or browser; reads your repo, edits files, runs commands, and ships changes.

Powered by GPT-5.5, with a polished desktop GUI, parallel agent threads via Git worktrees, and a /goal system for long autonomous tasks. Deep GitHub, Slack, and Linear integrations, and it uses the open AGENTS.md memory standard. A strong alternative to Claude Code.

Best for Founders who want a coding agent with a rich GUI and deep workflow integrations.

Visit Codex Founder guide

Vercel Deployment

The fastest way to deploy a web app — push code, get a live URL in seconds, no server config.

Connects to your Git repo, auto-detects the framework, and deploys to a global edge network. Every push triggers a build; every pull request gets its own preview URL; production deploys on merge. Serverless and edge functions handle API routes without managing servers.

Best for Zero-config hosting with a preview URL for every change — the production home for your repo.

Visit Vercel Founder guide

Get the code into GitHub. From AI Studio's Build mode, push your app to a GitHub repo (or download the ZIP and push it). This is the cleanest handoff in the whole pipeline — a standard repo, not a proprietary export.
Open it in Claude Code. Clone the repo, cd into it, and run claude. It reads your entire codebase at once — front end and server. Codex works the same way as an alternative.
Hand it your spec set. Point it at PRD.MD, TECH_STACK.MD, UI.MD, DESIGN.MD, DATA.MD, and API.MD. Now the agent has the same context you do.
Build in plain language. "Add X." "Fix the bug where Y." "Make this faster." It edits across files, runs the app, writes tests, and ships commits and pull requests.
Deploy on real rails. Connect the GitHub repo to Vercel — every push to your main branch deploys automatically. Keep the database on Supabase or Neon.

Done when you have a repo you — or a developer — can keep building on.

This is the Full-stack version — and the on-ramp to a real production app.

Pick your exit

Where to stop

The cycle is one path, but you do not have to walk all of it. These are the four places founders most often stop — pick the one your hypothesis actually needs. Going further than that is not progress; it is delay. The fastest credible test wins.

01 Stops after Stage 01

Frontend-only

A clickable, good-looking UI on a shareable URL. No backend.

Best for: Landing pages, clickable demos, testing whether anyone wants it.
Build with: Stitch, Claude Design → deploy on Vercel.

02 Stops after Stage 02

Full web app

A working app a real person can use — no accounts, nothing saved between visits.

Best for: Single-user tools, testing whether the core flow actually works.
Build with: Google AI Studio Build mode → deploy to Cloud Run.

03 Stops after Stage 03

App + backend

Real accounts and data that persists across visits and users.

Best for: Multi-user products, testing retention and real usage.
Build with: AI Studio + Firebase, or your builder + Supabase.

04 Walks all four stages

Full-stack

A real codebase you own, in a repo, on production rails.

Best for: Technical founders, or anyone with a developer, heading for production.
Build with: Claude Code or Codex → Vercel + Supabase / Neon.

A branch off the cycle

Going mobile

The cycle above is web-first — and for a prototype that is almost always the right call. A web app reaches every phone with no install and no app store. When your PRD genuinely needs a phone experience, you have two realistic paths inside a session:

Path A — PWA (recommended)

Any web app from the cycle installs to a phone. Open the URL on a phone and tap "Add to Home Screen" — it gets an icon and launches full-screen. Android support is first-class; iOS works with a few limits. Fastest thing you can hand a user to test today.

Path B — Expo Go preview

For a native-feeling preview, build a React Native app in Bolt with the Expo template and preview it on a real phone via the free Expo Go app — scan a QR code and it runs on your device.

App Store and Google Play submission is out of scope for a prototype session — it needs paid developer accounts, signing, a native build pipeline, and review that takes days. Build the PWA first, test with real users, then decide whether a native build is worth it.

Before you leave

Capture your work

When your prototype is working — meaning a real person could use it and give you a yes or no on your hypothesis — do two things before the session ends.

Save it.

Put the prototype in your 4_Dev_Projects/ project folder. If it is a live URL, create a file called prototype-day1.md and paste the URL and a one-line description into it. If it is a file or deck, save it directly. Day 3 and Peer Court locate the baseline using this folder and filename.

Write the hypothesis.

Complete this sentence and save it in the same file:

This prototype tests [what you built]. A pass = [what you observe when a user succeeds].

This sentence is your contract with Day 3 and Peer Court. It is a falsifiable test — not a tagline, not a vision statement. If you cannot complete it, your scope is not tight enough yet: go back to Section 5 of your PRD.MD and tighten the one flow before you build.