4.3a · The Self-Serve MVP Stack: Tools & Setup

By JetThoughts Team - May 18, 2026 - 14 min read

Module 4 · Step 3a of 4 · Part 1 of 2 · From Idea to First Paying Customer
Input: a Module 4 decision pointing to “self-serve” (from Ch 4.1) + a one-page brief (from Ch 3.1) + a Day-1 ownership audit passed (from Ch 4.2)
Output: the 3 pre-flight rules locked in, tool boundaries clear, ready to start the build in Part 2 · Build Phases

Jump to: What each tool does · 12 rules checklist · Communities · The ship plan

TL;DR: Lovable renders the screens, Supabase stores the data, Stripe charges the card. Three tools, three jobs. Know the boundaries before you open Lovable. Twelve rules keep the build inside the shed. All three tools have free tiers; the chapter’s specific cost callouts live where each tool is introduced. Skip to the ship plan if you already know the stack.

This chapter starts FRESH from your one-page brief - do NOT iterate the Chapter 2.4 prototype.
The Chapter 2.4 prototype was a short research artifact: fake data, no auth, viewed by 5 interview subjects, archived after the shape test. This chapter is the production build: real Supabase auth, real Stripe payments, real domain, real users. The first proved users can navigate the SHAPE; the second ships the actual product. Reusing the prototype code multiplies the build effort and ships every research compromise into production.

If you completed Modules 1-4, your default Module 4 path is to build it yourself with Lovable + Supabase + Stripe. Hiring is a ceiling-signal trigger covered in the supplementary reference, not a parallel choice.

You will not write code. You will spend two months running Mom Test calls before you touch a single tool, then start the build after the one-page brief is locked and the build-path decision tree routes you to Path 2.

The stack, top to bottom:

Layer	Tool	Job	Cost
UI	Lovable	Render the screens. Send form data down.	$0 free / $25 Pro / $100 Scale
Data	Supabase	Store the user, the row, the file. Listen for Stripe events.	$0 free / $25 Pro
Money	Stripe	Charge the card. Tell Supabase the customer is paid.	2.9% + $0.30 per transaction

The buyer opens the staging URL → Lovable shows the screens → Supabase stores the data → Stripe charges the card → a Stripe webhook tells Supabase the row is now paid.

Why these three tools, and why they slot together

Y Combinator’s current stance is direct: validate without code, then ship the simplest version with AI tools. Lovable + Supabase + Stripe became the dominant self-serve path because all three tools were built AI-first, their documentation is exhaustive, and the integrations between them are templated to the point of being boring.

Boring is what you want for an MVP. The boring path lets one non-technical founder ship the full loop (signup, paid onboarding, the one feature that solves the validated problem) without ever opening a terminal.

The cost to disprove your hypothesis is vendor free tiers and the small per-tool monthly fees in the cost table above. The cost to prove it is the same.

Alternative: $0 Concierge MVP (no-code Wizard of Oz). If you want more demand evidence before committing to Lovable code, run a Concierge MVP first: Tally (free form) → Zapier or Make.com (free routing) → Airtable or Notion (free storage). The customer fills the Tally form, Zapier drops the row in Airtable, you process by hand. To the customer it looks automated. Validate willingness-to-pay before committing to the build. All three tools have free tiers. This is a stepping stone, not a replacement; the Lovable + Supabase + Stripe stack is what ships in Part 2.

M2 prototype vs M4 MVP - different artifacts, different rigor

You do NOT polish your Module 2 prototype into the MVP. The prototype was throwaway by design. The MVP is built fresh with production rigor - real auth, real Stripe, real domain, real user data.

The Module 2 clickable prototype (Lovable in 2 hours) tested whether 5 interview subjects could navigate the SHAPE of the solution. It had no real auth, no payment integration, no production domain. Discard it.

The Module 4 MVP is built from the validated Product Brief with production rigor: real Lovable build with real Supabase auth + real Stripe + real custom domain + real user data. Different stack composition, different polish bar, different decision criteria.

Side-by-side: the Module 2 throwaway prototype vs the Module 4 production MVP.

	M2 prototype	M4 MVP
Time	2 hours	Days to weeks
Auth	None	Supabase auth
Payment	None	Stripe live
Domain	lovable.dev preview	Custom domain
Polish	Sketch-grade	Production-grade
Audience	5 interview subjects	Real signups + paying customers
Decision	“Should we build this for real?”	“Should we scale this?”

What each tool does (in plain English)

Pre-seed founders ask “which framework” before they ask “which job.” Three tools, three jobs. The boundaries between them are the only architecture you need to know on day one.

Lovable - the UI layer

Lovable is an AI-powered builder for the screens. You describe an app in English: “a dashboard for fitness coaches to log client check-ins, with a weekly export to CSV”, and Lovable generates a working web frontend with proper component structure, routing, and form validation. Every save deploys to a public staging URL you can paste into a Slack message.

Lovable’s pricing tiers in 2026 run $0 (Free, capped messages), $25/mo (Pro), $50/mo (Business), and $100/mo (Scale, the tier most paying-MVP founders settle on after the first month).

The key thing it does not do well: heavy backend logic, complex auth flows, anything custom on the database side. That is what Supabase is for.

Supabase - the data layer

Supabase is managed Postgres + auth + file storage + row-level security in one console. Lovable’s built-in storage is fine for a prototype; Supabase is what you connect when you have real users whose data has to survive a redeploy.

The free tier handles up to 50,000 monthly active users and 500MB of database before you have to upgrade. Pro is $25/month and most pre-seed founders never outgrow it before they hit the architectural ceiling.

Supabase auto-generates a REST API and a JavaScript client on top of any table you create, which is what Lovable calls when it needs to read or write a row. Supabase’s 2026 pricing lists the bands clearly. The auth product replaces 80% of what founders used to pay Auth0 or Clerk for; the row-level security policies replace what a contractor would have hand-coded over two weeks.

Stripe - the money layer

Stripe processes the payment. The 2026 default integration for a Lovable app is Stripe Checkout (a hosted page Lovable can link to with one line) plus a webhook into Supabase that updates the user’s subscription status when the charge succeeds.

The fee is the standard 2.9% + $0.30 per transaction for cards in the US; international, Klarna, ACH, and other rails have their own bands. There is nothing custom about this in 2026. Every founder hits the same Checkout integration; the documentation has been refined over a decade of pre-seed founders running the exact same setup.

GitHub for version control

Free for solo founders on the Free plan. You will not write much code yourself, but Lovable can sync to a GitHub repo on every save. Two reasons this matters: (a) you have a backup if Lovable goes down or you cancel the subscription, (b) when you eventually hire a contractor or a Fractional CTO, the code is already in a place they can read. Set this up in Lovable’s Settings on day one. Skipping this is the most common reason founders we pick up six months later cannot retrieve the source.

Module 4 AI critic/simulator block
What AI can help with at this stage:
Review your Lovable build against your one-page brief. Paste your brief’s Section 3 into Claude, then paste this prompt:
Here is Section 3 of my one-page brief (the outcome-shaped feature list). Based ONLY on this list, name 3 things a Lovable build of this brief would likely include that are NOT in the list. Be specific - feature names, not categories.
Audit your Supabase RLS policies. First, in the Supabase Dashboard, open Table Editor, click each table, click the Definition tab, and copy the SQL shown. Paste all your table definitions into Claude with this prompt:
Here are my Supabase table definitions. Which tables lack row-level security (RLS) enabled, and for each one, name the cross-tenant data leak that would result if a logged-in user from Tenant A queried that table. If you cannot determine the leak without seeing the application code, respond with "NEED CODE: [which file]" rather than guessing.
Walk the happy path from static input. Open Lovable in your browser, take 3 screenshots (sign-up screen, the one core-action screen, and the paywall / payment screen) and paste them into Claude one by one along with Section 3 of your brief. Prompt:
Here is the signup-to-paywall happy path from my MVP plus the outcome-shaped feature list it was meant to ship. For each screenshot, name any screen, button, or field that is NOT in the outcome list - these are scope leakage you can cut before launch. If a screen looks aligned to the outcome, say so explicitly.

If you cannot identify any scope leakage in a screenshot, respond with "NO SCOPE LEAK FOUND" - that is a valid finding, not a failure.
Claude cannot audit a URL it cannot browse; it CAN audit screenshots you provide.
What AI cannot prove or substitute:
Whether real users can navigate the workflow (only uncoached ICP users can)
Whether the Stripe webhook idempotency is correct (only test-mode charges can)
Whether the architecture will hold at scale (only real traffic + Ch 4.4 ceiling signals can)
The real gate: 5 green lights (Phase 4 exit criteria in Part 2) + weekly demo to one non-PRD-reader human.

12 rules for a self-built PoC done right

How to read this list. 3 rules need to be true BEFORE you open Lovable. The rest fire inline during the Phase 1-4 build in Part 2. If you internalize ONLY the 3 pre-Lovable rules + the Phase 4 exit criteria, you ship a working MVP. The other rules are inline reminders, not a homework checklist.

Synthesis of every rule scattered across Module 4 and the supplementary references. Print this page, tape it next to the laptop, re-read before every weekly demo.

Before you open Lovable - the 3 load-bearing pre-flight rules. Rules 1, 2, and 6 in the list below are the ones that must be true on day zero. Rule 1 (one-page brief passed the Ch 3.2 quality-gate) keeps Phase 1 prompts from generating a 47-button admin panel. Rule 2 (one workflow, one persona, one happy path) keeps the build inside the shed. Rule 6 (GitHub sync turned on in Lovable Settings on day 1) keeps your source recoverable if Lovable drops it. Get those 3 right and the rest read as inline checks while you build. Get them wrong and the other 9 cannot save the project.

Start from a one-page brief that passed the Ch 3.2 quality-gate. If Section 3 is feature-shaped, fix it before you open Lovable. Feature-shaped briefs produce 47-button admin panels.
One workflow, one persona, one happy path. No multi-tenancy, no admin dashboard, no settings page on day one. Build the shed (Rob Walling’s analogy), not the house.
Strict layer boundaries: Lovable renders screens, Supabase stores data, Stripe collects payment. Do not let Lovable hand-roll auth; do not let Supabase render a UI; do not let Stripe become the source of truth for user state.
Weekly demo to one non-PRD-reader human. Spouse, advisor, dog if necessary. Keep a ship-something-visible cadence every week. The demo IS the data; the screens are not.
Do NOT iterate the Ch 2.4 throwaway prototype. Start the M4.3 build fresh from your one-page brief. The prototype answered “do users know what to click”; the MVP answers “do users pay.”
Set up GitHub sync in Lovable Settings on day 1. Lovable can drop the work; GitHub is your backup. Skipping this is the #1 reason founders cannot retrieve their source.
Enable Row-Level Security on every Supabase table from day 1. RLS is the rule that says “Coach A can only read Coach A’s rows.” Skipping it ships the cross-tenant data leak that ends pilots (see Ch 4.4 Signal 4).
Stripe webhook handler must be idempotent. Idempotent means “safe to run twice without breaking anything” - Stripe sometimes sends the same payment event more than once, and your handler must not double-charge or double-activate. Check WHERE event_id = $1 AND processed = true before re-running the update. (See production hardening section of hire-track reference for details.)
Budget envelope: vendor free tiers + per-tool monthly fees. Lovable free, Supabase free, Stripe transaction fees, domain registration. Upgrade Lovable to $25/mo Pro only when build velocity demands it.
Ship before scope creep, then a short stabilization phase. Build the smallest end-to-end thing, then a stabilization phase before paid-pilot conversations. Sits inside the multi-month journey to first paying customer.
Monthly Ch 4.4 ceiling-signal check once the live MVP is up. Even if everything is green, the habit catches the 5 architectural break-points before they become rebuilds.
Do not scale a Lovable stack past ~5K users or 2 ceiling signals at red. When you hit either limit, graduate to a Fractional CTO bridge (see hire-track reference). The shed is not the house; pouring skyscraper foundations into a shed slab does not build a skyscraper.

Each of the 12 rules is taught in depth somewhere across this chapter, the self-serve stack walkthrough, Ch 4.4 ceiling signals, or the hire-track supplementary reference. The list above is the index; the surrounding chapters are the depth.

Communities that replace a co-founder

You are about to hit a wall: a Lovable prompt that produces the wrong component, a Supabase RLS policy that locks out your own admin user, a Stripe webhook that fires twice for one charge. Five communities answer most of these in under an hour, free.

Community	Members / Tiers	Best for	Cost
Lovable Discord	160K+ (2026)	Real-time UI troubleshooting; Lovable team answers in channels; hosts monthly hackathons	Free
Indie Hackers	Bootstrap-focused	Honest revenue posts + shipping logs; Friday-demo accountability rhythm	Free + paid tier (varies)
No Code Founders (NCF Slack)	Full no-code stack (Bubble, Webflow, Glide, Softr)	If Lovable is wrong for your UI shape; worth membership even if you stay on Lovable	Free membership
r/nocode + r/vibecoding (Reddit)	Free, indexable	Lower signal-to-noise than Slack; search before post	Free
Buildspace + Maven cohorts	Drew Falkman’s “Vibe Coding Data-Enabled AI Apps” (~$1K)	Peer cohort + office hours; for founders who ship harder under deadline	~$1,000

None of these is JetThoughts. None of them sells you a service. They are the founder peer pool the YC stance on co-founders now points at instead of the 50%-equity hire.