Full Reference: The Self-Serve MVP Build, Phase by Phase

Reference companion to Lesson 4.4 · The Self-Serve MVP Stack: Build Phases - the step-by-step version of the four build phases, plus the onramp that hands you off to Module 5. Read the micro-lesson first for the minimum effective path; return here when you want the full mechanics for the phase you are on.

This guide picks up where Lesson 4.3 · Tools & Setup leaves off - stack set up, pre-flight rules locked, idea validated in Modules 1-3. Skip the validation and you ship into silence.

Calendar reality: plan the 10-12-week evening-only version, not the 4-6-week full-time one (Lesson 4.4 has the breakdown). Phases 2 and 3 are where part-time founders lose the most calendar.

Phase 1 - write your prompts, set up Lovable, ship the UI #

Start by opening the one-page brief. The “what you’re building” section becomes your first three Lovable prompts.

Lovable’s prompt style is conversational; you describe the screen, the components, the rough behavior. Examples:

Build a dashboard for a fitness coach. Top-level view shows
a list of clients (name, last check-in date, status: green
if checked in this week, red if not). Click a client to open
their detail page with a check-in form (date, weight, notes,
3-photo upload).

Lovable generates the screens. You iterate by chatting with it: “make the status badges bigger, move the check-in form to the right side.” By the end of the phase you have a clickable UI on a public staging URL. No data persists yet. That is fine. The phase demo is to your spouse: do the screens make sense without any explanation? If the screens need a tour to understand, the design is wrong, not the build. Rewrite the prompts.

Phase 2 - set up Supabase, connect, real signup works #

Create a Supabase project on the free tier. Define your three or four core tables in the SQL editor (or in the Table Editor UI; both work for an MVP). For the fitness coach example: coaches, clients, check_ins. Enable Row-Level Security from the start. RLS is the difference between a coach seeing their own clients and a coach seeing every coach’s clients in a single bug. Skipping it is the most common security mistake we see in vibe-coded MVPs.

First-table walkthrough (for the fitness-coach example - adapt to your domain): in Supabase Dashboard, click Table Editor in the left sidebar, then New table. Name it coaches. Check the “Enable Row Level Security (RLS)” box BEFORE adding columns. Add columns: id (uuid, primary key, default gen_random_uuid()), email (text), user_id (uuid, foreign key to auth.users.id), created_at (timestamp, default now()). Click Save. Repeat for your second and third tables. The RLS checkbox is the load-bearing click - if you forget it on table creation, you’ll have to manually enable it later AND backfill policies on existing rows.

In Lovable, install the Supabase integration. Lovable will add the Supabase JS client and store the keys for you. Wire your signup screen to supabase.auth.signUp() and your data screens to supabase.from('clients').select(). The phase demo: your spouse signs up via the staging URL, you watch a row appear in the Supabase console in real time.

Self-test your RLS policy before going live (two paths).

Same audit as the Lesson 4.3 pre-flight rule - now run it against your real tables.

No-code path (the default for a non-technical founder - this is copy-paste verification, not programming: the AI writes the fix, you paste it and read the answer). In Claude or ChatGPT, paste: “Audit my Supabase RLS policy. Here is my schema: [paste your table definitions from Supabase Table Editor]. Here is my current RLS policy: [paste from Authentication -> Policies]. Tell me whether a logged-in user with a fake user-id can read rows that belong to other users. If yes, give me the exact policy SQL to fix it.” Paste the AI’s suggested policy into Supabase Authentication -> Policies.

SQL path (only if you are comfortable writing SQL). In Supabase Dashboard -> SQL Editor, paste the test below, replacing <table> with your main user-data table. The pretend user-id 999 has no real rows; if the query returns any, your policy has a hole.

SET ROLE authenticated;
SET request.jwt.claims = '{"sub": "00000000-0000-0000-0000-000000000999"}';
SELECT * FROM <table>;
RESET ROLE;

Zero rows back = policy works. Any rows back = the policy is missing a USING (auth.uid() = user_id) clause or equivalent. Fix before any real user touches the URL.

End-of-Phase-2 micro-fail signal. Before you build Stripe in Phase 3, hand the staging URL to your spouse OR one of your Lesson 2.3-2.4 Mom Test interviewees. Give zero coaching. Watch them try to sign up and reach the core action button (logging a check-in, exporting the CSV, whatever your one-page brief named as the workflow). If 2+ test users stall on screens 1-2, the workflow shape is wrong - pivot back to Lesson 3.2 outcome rewrite before adding Stripe. Building a payment wall on top of a workflow nobody can navigate just adds friction to a broken loop.

Phase 3 - add Stripe, wire checkout, $1 test transactions #

Create a Stripe account in test mode. Build one product (your monthly plan) at one price (the price your Lesson 1.5 smoke test validated). Use Stripe Checkout for the simplest possible integration: one URL Lovable links to, one webhook (a webhook is an automatic message Stripe sends your app the moment a payment succeeds - you don’t write code to call Stripe; Stripe calls you) back to Supabase that flips the coaches.subscription_status column to active when the charge clears.

Spend the rest of the phase running $1 test transactions through the flow: signup, hit the paywall, pay $1 in test mode, land in the paid view. Use Stripe’s test card numbers to simulate failures (declined card, 3D Secure challenge, dispute). The phase demo is to yourself: you sign up as a fake coach, you pay $1, you land on the paid dashboard, you check Supabase, the row says paid. Webhook works.

Phase 4 - deploy, send to 5 ICP users, iterate from the data #

Switch Stripe out of test mode. Buy a domain (roughly $10/year for a .com on Porkbun or your registrar of choice; never let a tool hold your domain). Point the domain at the Lovable staging URL. Take final screenshots, write a 3-line cold email or LinkedIn DM, and send to 5 ICP prospects from your Module 2 outreach list.

“Hey [NAME] - the workflow you described recently (logging client check-ins by hand on a spreadsheet) is now a tool. Quick first-use, $29/month after a trial window. URL: [STAGING_URL]. Honest reactions only.”

Watch what happens. Lesson 4.4’s Phase 4 block maps each failure shape (no clicks, no signups, no payments) to the next fix. The demo is the data, not the screens.

Phase 4 exit criteria - the five green lights. Lesson 4.4 lists each light with its exact check. Advance to Module 5 only when all five are green; a red light means the MVP is not ready for the 10-30 users Module 5 needs.

Pre-flight before M5.1: book up to 10 user sessions. The onramp phase typically yields 4-6 accounts - not enough for M5.1’s Sean Ellis 40% test (under 10 respondents = noise, not signal). Before you start Module 5, book a second small invite wave: 5-10 more sessions from your Lesson 2.3-2.4 interviewee list, your community connections, or a fresh micro-batch of cold DMs. Aim for 10-30 active users by the time M5.1’s survey ships - 5.1 treats 10 as directional-only and 20+ as a useful read. Without this pre-flight, you will run the 40% test on 5 people, get an ambiguous result, and falsely conclude you have a product problem when you really have a sample-size problem.

Onramp phase - Module 5 handoff: invite your Module 2 interviewees onto the live MVP #

The build phases above are the BUILD container; the onramp turns the live staging URL into a live users table. The invite wave itself - the 3-line personal note to each of your 10 Lesson 2.3-2.4 interviewees - is a required course step and lives in Lesson 4.4’s Module 5 handoff, with the note recipe and the honest conversion expectations. “Create an account” is not “pay” - paid conversion happens in Module 5.

If you need more than 10 users on the MVP before running Lesson 5.1’s survey, the recruitment playbook in Lesson 2.3-2.4 is the same one you use to find them - the message changes from “30 minutes of your time” to “try the live tool for a week, free.”

What “ship the shed” means in practice #

Lesson 4.1 · Should You Hire? walked through Rob Walling’s shed-vs-skyscraper warning: you build the smallest structure that does the job, and you do not pour skyscraper foundations for it. Lovable + Supabase + Stripe is the shed.

Be honest about the trade-off. This stack cannot host every business; the first 10 paying customers are the data point that earns the next architecture argument.

What the stack actually costs #

Per published vendor pricing:

The architectural ceiling tends to land at the post-launch tier - at roughly 5,000 users, route to Lesson 4.5 · Ceiling Signals or a Fractional CTO. A hire-a-team build is material monthly burn before revenue; this stack ships the same first 10 paying customers on a fraction of that.

When this path ends #

Self-serve has a ceiling. Lesson 4.5 · Ceiling Signals covers the 5 signals that mean it’s time to bring in help. When 2+ signals fire across two consecutive monthly checks (the 4-week rule from Lesson 4.5), switch to the hire-track supplementary reference. Architecture does not collapse overnight; the warning shows up in the metrics before the customer sees it.

The Self-Serve Stack Walkthrough artifact is the day-by-day version of these phases. Print it before Phase 1. Each day has one small task; each phase has one demo. The artifact removes the “what do I do next” question, which is the reason most small ships actually finish.

Further reading #

• Lesson 4.3: Tools & Setup - why these three tools, what each one does, the 3 pre-flight rules, and the AI critic block
• Stack & Tools reference - each tool in depth, the M2-vs-M4 contrast, all 12 build rules, and the founder communities
• Self-Serve Stack Walkthrough - day-by-day version of the build plan; print before Phase 1
• Y Combinator, Startup School Library + 2026 Founder Resources - the YC stance on validating without code

Built by JetThoughts as a companion reference to the From Idea to First Paying Customer free curriculum.