Build a SaaS on Lovable: The Foundation Prompt, the Schema That Proves Its Policies, and the Billing Step

What order avoids rework?

The one where each step is proven before the next depends on it. Accounts before roles, roles before any screen that hides by role, the schema before the features that write to it, a landing page before billing, and billing wired so the webhook is the only thing that grants access.

Step one: the foundation prompt, and what it cost

The prompt is SaaS MVP with User Auth from the SaaS prompts: email and password auth that survives refresh, a workspace on first sign-in, three roles, invite by tokenised link, role-gated UI, and the safeguard that roles are enforced in the database. Run on 2026-09-26 for 10.4 credits: it asked 4 questions, enabled Cloud, self-tested sign-up and invites, roles checked in the database.

The prompt examples page has the four questions it asked first and the rest of the screenshots.

Step two: the schema, counted from the file

The SaaS starter kit ships the database the foundation prompt expects. The numbers below are read from its files when this page is built, so they cannot drift from what you download.

The traps the kit was written around: a recursive policy on the membership table, and a member promoting themselves to owner through an update policy without a with-check clause. The Lovable and Supabase guide has the three shapes of that failure.

Step three: prove the policies deny

Lovable's Quick and Deep scans confirm that row-level security is present on a table. Neither runs a query as the wrong user, which is the only proof a policy denies. The kit's verify.sql does: sign in as an ordinary member, read another workspace's rows, promote yourself to owner, and expect both to fail. On the Cadence build the Deep scan reported nothing at any severity and the dependency panel listed two known issues; the security page has the run and the distinction.

-- Verification queries. Run these as an ordinary signed-in user, not as service_role.
-- Every one of them must behave as described or a policy is wrong.

-- 1. Should return only workspaces you are a member of, never every workspace.
select id, name, plan from public.workspaces;

-- 2. Should return zero rows for a workspace you do not belong to.
--    Substitute a workspace id you are NOT a member of.
select * from public.workspace_members
where workspace_id = '00000000-0000-0000-0000-000000000000';

-- 3. Should FAIL for a member (non-admin). If it succeeds, the write policy is too loose.
insert into public.workspace_members (workspace_id, user_id, role)
values ('<a workspace where you are role=member>', auth.uid(), 'owner');
...

Step four: the landing page, before billing

A SaaS with no sign-ups does not need a checkout. The six-section SaaS landing page prompt was run on 26 September 2026 for 4.5 credits in a separate project so its analytics stay clean; it counts sign-ups against visitors from one channel, which decides whether steps five and six are worth building.

Steps five and six: the mechanics, then billing

The SaaS category holds 15 mechanics prompts. The five that turn a working app into a chargeable one, in the order their build sections assume:

Billing itself is the Lovable and Stripe page: built-in payments on a paid plan or your own key on Free, Stripe's rule that the success page is not proof of payment, and this site's own webhook with its two idempotency layers. The rule that survives every path: the webhook is the only writer of entitlement, and the member page only reads.

What do the top results for this term leave out?

• Base44, How to build a SaaS product. About 2,400 words, 10 May 2026, eight steps, three third-party statistics, no build shown; the CTA is the builder.
• Syndicode, How to Build a SaaS Product. About 8,500 words, 2023, eight steps, a hypothetical estimate of $174,000 to $396,000 and 44 to 82 weeks; agency case studies; the CTA is the agency.
• A Medium post on building a SaaS in five hours with AI. Blocked to our fetch, so it is listed, not characterised.

What we did not publish

• Steps five and six as runs. The mechanics prompts and the billing step are documented, not executed on Cadence; the page says which steps carry a credit figure and which do not.
• A customer. The build has no users and no revenue; the landing page exists to find out whether it should.
• A timeline in weeks. The measured day is on the how-to-build-an-MVP page; extrapolating it to a launch would be a guess.

Sources

Kit counts from src/data/templates.ts at build time; runs from src/data/runs.ts and src/data/mvpLedger.ts; read 26 September 2026.

• Lovable docs: Add payments to your app
• Lovable docs: Security overview
• Base44: How to build a SaaS product people want to use
• Syndicode: How to Build a SaaS Product