From Lovable prototype to paying customers: the 6 things you have to fix before launch.

Where this comes from

Most clients I take on these days come to me holding a Lovable / Bolt / v0 prototype that "works" and asking how to start charging for it. The prototype is real. The product gap is also real. After 11 of these conversions, the gaps repeat. Here's the punch list, ordered by what kills launches first.

1. Billing that actually handles failure

The demo has Stripe Checkout. Good. The demo does not have:

• A failed-payment retry flow (try again at 3, 7, 14 days)
• A "card declined" UI for the user (not a 500)
• A "subscription paused" state when the retry runs out
• A way to update the card mid-subscription (Stripe Customer Portal)
• Webhook signature verification (the demo trusts the webhook blindly)
• Idempotency keys on subscription creates

This is 80% of every billing fix I do. Half of MRR loss in early SaaS is failed payments that were never retried.

2. Error states on every list and form

Demos work because the test data fits. Real users hit:

• Empty state — what does the dashboard look like with 0 records?
• Slow state — what happens when the API takes 4 seconds?
• Error state — what happens when the API returns 500?
• Long state — what happens with 5,000 records (pagination, virtualization)?
• Network state — what happens when the user is offline?

The demo has none of these. The product needs all of these. About a day of work, total.

3. Observability you can actually read

The demo has whatever the platform gave you for free. The product needs:

• An error monitor (Sentry, Cloudflare Logpush, similar) wired to a notification channel
• A simple metrics dashboard — sign-ups, MRR, churn, top errors
• A morning report that tells you what happened yesterday (see three apps on autopilot)
• Slow-query alerts on the database

Without these, you discover problems through customer emails. With these, you discover them while customers are still happy.

4. A support channel that's not your phone

The demo has no support. The product needs:

• A "help" link in the app that opens a real inbox or chat
• An email template for "thanks for writing in" so users feel acknowledged in < 1 hour
• A FAQ page with the 5 questions you'll be asked (you already know them)
• A status page (free option: a static page, even on a sub-domain)

Status pages are oddly underrated. The number of times "is the site down?" turns into a 30-message Slack thread because there's no source of truth — every product owner learns this once.

5. Abuse prevention at the front door

The demo has a sign-up form. The product has:

• Rate limiting on the sign-up endpoint
• CAPTCHA or Turnstile for high-volume forms
• Email verification (real, not just "we sent an email")
• Disposable-email blocking on paid tiers
• Rate limits on every authenticated endpoint, not just sign-up

The day your demo gets posted on a forum is the day you discover whether you have these. Easier to add Turnstile in a quiet week than during a 3 AM bot wave.

6. The boring legal page

You need:

• Terms of Service (template + lawyer review = $200-500)
• Privacy Policy (especially if you collect anything in EU)
• Cookie banner (only if you actually use non-essential cookies — most apps don't)
• A "delete my data" endpoint (GDPR, CCPA — also the right thing)
• A registered company if you're charging — Stripe asks

Most freelancers skip this and assume the client will handle it. The client expects you to handle it. Have the conversation. Either way, the launch waits on this.

The order of operations

If you only have a week before launch, fix in this order:

1. Billing failure handling (#1) — every day without this loses money
2. Error states (#2) — biggest impact on first-impression conversion
3. Legal pages (#6) — Stripe and Apple/Google won't let you ship without them anyway
4. Observability (#3)
5. Support channel (#4)
6. Abuse prevention (#5) — important but rarely day-1 critical

If you have a month, do them all. If you have less than a week, do #1, #2, and #6 — and tell the client the others are on the post-launch sprint.

None of these are exotic. They're just none of them in the prototype. AI builders skip the boring half. The boring half is the half that turns a demo into a business.

How buildr handles this

If you ask buildr "make this production-ready for paying users," the agent runs through this same six-item checklist. It drafts the Stripe retry flow, the error states, the abuse rate-limits, and the legal pages (with placeholders for your jurisdiction). I still review every change. But the checklist is the checklist.