Why "it works in the demo" isn't the bar

A vibe-coded prototype can look completely done - clean UI, working flows, a working checkout button - and still be nowhere near ready to charge a real customer. The gap is almost never visual. It's four specific, unglamorous things a loose natural-language prompt never asks an AI agent for: who's allowed to see this data, what happens when a subscription lapses, whether one customer's data can leak into another's view, and what happens when a webhook fires twice. None of these show up in a demo. All of them show up in week one of real usage.

The four building blocks of a paid MVP

MVP foundation

Auth, routing, and a real database schema - not mock data - from the first commit. The foundation an AI agent generates by default rarely assumes multiple tenants or paying customers unless the prompt says so explicitly.

Data safety

Row-level security (or equivalent tenant isolation) enforced at the database layer, not just checked in application code - the difference between "usually correct" and "provably correct."

Billing

A real payment provider integration (subscriptions, one-time charges, webhooks) with idempotency handled from day one - see our piece on the cost of skipping idempotency in payment webhooks.

Entitlements

The logic that actually gates features by plan - "is this user allowed to do this right now" - kept in one place, not scattered as ad-hoc checks across every screen an AI agent touched.

A build plan, not just a prompt

The difference between vibe coding a demo and building a paid MVP is sequencing. Each block below should be a deliberate prompt with its architecture stated explicitly - not left to whatever the model assumes.

1

Foundation first. Auth, org/tenant model, and core schema - prompted with the multi-tenancy and data-ownership rules stated up front, before any feature screens exist.

2

Data safety before features. Row-level security policies written and tested against the schema before building the UI that reads from it - retrofitting isolation after screens exist is much slower.

3

Billing as its own vertical slice. Checkout, webhook handling, and idempotent processing built and tested in isolation, not bolted onto whichever screen needed a "Buy" button first.

4

Entitlements as a single gate. One function or middleware layer answering "can this user do this," called everywhere feature access matters - not copy-pasted checks per screen.

What this looks like as a prompt

// Vibe-coding prompt (implicit, risky)
"Add a pricing page and let users subscribe."

// Prompt-driven equivalent (explicit architecture)
"Add a pricing page with Stripe Checkout for two plans. On successful
checkout, the webhook handler must be idempotent (dedupe on Stripe's
event ID), update the user's entitlement row in one transaction, and
never grant access before the webhook confirms payment - not on
redirect alone, since redirects can be spoofed or interrupted."

The detail most prompts skip: granting access on the checkout redirect instead of waiting for the webhook. Redirects can fail to fire, get closed early, or be replayed - the webhook is the only trustworthy signal that payment actually succeeded.

Where teams get stuck

No tenant isolation until it's urgent

Data safety gets added after the first customer asks "can other companies see my data?" - a much harder retrofit than building it in from the schema up.

Entitlements scattered per screen

Feature-gating logic copy-pasted into every component that needs it, so a plan change requires hunting down every copy instead of editing one gate.

Billing without idempotency

A webhook redelivery double-grants access or double-charges - the exact failure mode covered in our notification and payment idempotency pieces.

Key takeaways

  • A working demo and a paid MVP differ in four specific places: auth/foundation, data isolation, billing, and entitlements - not in visual polish.
  • Sequence the build so data safety and billing are deliberate, isolated steps - not features bolted onto whichever screen needed them first.
  • Grant access on webhook confirmation, never on redirect alone - redirects aren't a trustworthy payment signal.
  • Keep entitlement checks in one place - a single gate function, not scattered per-screen logic.
  • Every one of these decisions should be explicit in the prompt, not left to the model's default assumptions - the same discipline covered in our PRV Cycle piece.
If you've got a vibe-coded prototype that's ready to take real customers and real payments, a short architecture review is usually enough to map exactly what's missing before launch.