From prompt to production: what's true first

As of October 15, 2026, an AI-built app is production-ready when its data model, server-side permissions, money path, sign-in, backups, rollback and error alerts all hold up for real users, and none of that is visible in the prototype.

The data model holds the whole product, not just the first screen. Permissions are enforced on the server, where the browser cannot reach them. The money path is tested end to end, not just at the point of payment. Sign-in works for a stranger, not only for you. You have backups you have actually restored, and a way to roll a bad release back. And errors reach a named person before customers report them. A working Lovable prototype has answered the one question that matters most early, which is whether the thing is worth building. The list above is everything else.

This guide is for a founder who has that working prototype and wants to take it live for real paying users. It is the map, not the territory: each part below gets the short version and then a link to the article that owns it in full. Read it top to bottom once to see the whole distance, then follow the links for the piece you are standing on. Platform facts about Lovable, Supabase and Stripe come from their own documentation, checked on October 15, 2026 and listed under Sources.

What does production-ready actually mean?

It means the app behaves correctly when the people using it are not you, the data in it is real, and nobody is watching the screen when something breaks. A prototype is tested by its maker, with made-up data, on a good day. Production is used by strangers, with data they care about, at the moment you are asleep.

Everything that follows is a way of closing that gap. The order matters: data and access come first because a mistake there leaks information you can never un-leak, and the later items only decide how bad a bad day gets.

Lovable itself draws the same line. Its security view runs a quick scan automatically when you publish and a deeper scan you start by hand, and its documentation is blunt that these "do not replace a thorough security review" and that you should "review and resolve critical issues before making your app publicly available." The scan is a smoke alarm, not a building inspection. The sections below are the inspection.

Does your data model have to change before launch?

Usually, yes: the tables need declared relationships, constraints and indexes, and this is the part founders skip because the prototype hides it. When you build screen by screen with a prompt, the tables end up shaped like the first screen rather than the product.

Relationships are implied instead of declared, there are no constraints to stop impossible states, and the columns you filter on are not indexed, so the list page that felt instant with ten rows crawls at a thousand. These are the decisions you make once and pay for forever, which is exactly why they are worth getting right before real data arrives and makes them expensive to undo.

The fix is not glamorous: declare every relationship and primary key, add constraints that make bad states impossible, index what you query, and write down which tables hold personal data and how long you keep it. The data and recovery items in the production readiness checklist walk through each check in plain language, and if the app is already slow with real traffic, why your Lovable app gets slow with real users covers the usual causes.

Where do permissions have to be enforced?

On the server, every time, for every read and write. A prototype often controls access by hiding buttons: if you cannot see the delete button, you cannot delete. But anything the browser sends can be changed by the person sending it, so a hidden control is a suggestion, not a rule.

This is the single most common way AI-built apps leak data, and it has its own article: when Lovable users can see each other's data.

With Supabase, the mechanism is row-level security. Supabase's documentation describes RLS policies as "granular authorization rules that run inside the database," executed "every time a table is accessed," like a WHERE clause added to every query. Two facts from those docs decide whether yours is safe. First, enabling RLS with no policy denies everything: "no data is accessible through the API when using a publishable key, until you create policies." Second, the service_role key bypasses RLS entirely, so it must stay on the server and never reach the browser. A key in client code is the other classic leak, covered in what to do when a Lovable API key is exposed. For the policies themselves, Supabase RLS policy examples shows the patterns, and the security risks of vibe-coding explains why this class of bug is so easy to ship by accident.

Which rules you are legally on the hook for depends on what data you hold and who your users are. That is a separate question from the technical one, and which rules your product must meet is the piece that owns it.

How do you know the money path actually works?

You test it end to end, and the end is not the payment. The failure that costs you customers is the one where Stripe takes the money and the account never upgrades, because the app decided the purchase succeeded from the browser redirect instead of from Stripe.

Stripe's own fulfillment guide is explicit: "You can't rely on triggering fulfillment only from your checkout landing page, because it's not guaranteed customers visit that page," for instance if someone pays and then loses their connection before the success page loads. Fulfillment has to be driven by a webhook.

That webhook carries three requirements straight from Stripe's documentation. Verify the signature on every event, using the raw request body, the Stripe-Signature header and your signing secret, because "an attacker could send fake webhook events to your endpoint to trigger actions like fulfilling orders." Expect duplicates and handle them: Stripe says endpoints "might occasionally receive the same event more than once," so you log the event IDs you have processed and skip repeats. And do not depend on order, because Stripe "doesn't guarantee the delivery of events in the order that they're generated." The listen-for-checkout.session.completed-then-fulfill shape, done so it is safe to run twice, is the whole game. The specific symptom and its fixes live in Stripe paid but the account did not upgrade, and the broader testing discipline is in how to test an AI-built app.

Will sign-in work for real users, not just you?

You only know once you test it the way a stranger would. This is the one that passes every test you run and fails for your first customer, because you test it signed in as yourself, on the preview URL, with an account that already exists.

A real user arrives at the published domain, with a brand-new email, and hits whatever you forgot: a redirect URL that only lists the preview address, a confirmation email that only reaches your own team, or a provider that was never configured for the live site. The test that matters is a brand-new account, in a private window, on the real domain, with an email you have never used. The sign-in and email side of this is covered in how to test an AI-built app, and the testing group of the production readiness checklist lists the exact journeys to run.

What happens on your worst day?

The worst day is the one where data is gone, and the only thing that helps is a backup you have already restored. On Supabase, how much you can get back depends on your plan. Supabase automatically backs up Pro, Team and Enterprise projects daily, keeping 7 days on Pro.

Point-in-Time Recovery is a paid add-on that, in Supabase's words, backs up write-ahead-log files "at two-minute intervals" and "achieves a Recovery Point Objective (RPO) of two minutes," meaning your worst-case loss is about two minutes of data rather than a whole day. Free-tier projects get no scheduled backups at all and have to export their own data with the CLI. Knowing which of these you are on, in minutes rather than guesses, is the point.

A backup nobody has restored is a hope, not a backup, so restore one into a copy before you need it for real. Recovery also means being able to put a bad release back without a code change, which in Lovable means knowing how to return to the last working version and republish. The full treatment is in Supabase backups and disaster recovery, and the monitoring that tells you a bad day has started, errors and uptime reaching a named person rather than a mailbox nobody reads, is the support group of the production readiness checklist.

When should you get help?

Get help when there is a part of this map you cannot hold yourself, and be honest about which parts those are. If you can read the list above, run the checks and fix what you find, you may well not need anyone. Many founders can get the data model and auth right with patience.

The two parts where a mistake is quietest and most expensive are server-side permissions and the money path, because both pass a casual test and fail in production, and both involve other people's data or money. If those make you uneasy, that unease is accurate.

Getting help does not mean handing the project away. It can mean handing an AI-built app to developers for a defined piece of work, or it can mean the vibe-coding rescue service, where our engineers take what you built in Lovable and make it safe to launch while you keep prompting. Either way, start by seeing where you stand: the free production-readiness check asks a short set of questions, scores your app out of 100 and names your three biggest risks, with no code to read.

If you want engineers to carry every item on this map rather than just the one worrying you, that is what the monthly subscription is for: code review, security checks, monitoring around the clock and twice-weekly releases, while you keep designing the product in Lovable. The wider walk-through is the guide to taking a Lovable app to production, with the security half in the Lovable security checklist, and what working with us costs is on pricing. Either path, the destination is the same: the thing you prototyped, now safe to hand a stranger.

Sources

All platform facts were checked on October 15, 2026, against the vendors' own current documentation. Prices and plan limits were re-checked on October 22, 2026. We review this page every 30 days.

• Lovable documentation: Security, on the quick and deep scans, resolving critical issues before publishing, and that the tools do not replace a thorough security review (docs.lovable.dev/features/security).
• Supabase documentation: Row Level Security, on policies running inside the database, enabling RLS denying access until policies exist, and the service_role key bypassing RLS (supabase.com/docs/guides/database/postgres/row-level-security).
• Supabase documentation: Database Backups, on daily backups and 7-day retention on Pro, Point-in-Time Recovery at two-minute intervals with a two-minute RPO, and free-tier projects exporting their own data (supabase.com/docs/guides/platform/backups).
• Stripe documentation: Receive Stripe events in your webhook endpoint, on verifying signatures with the raw body, handling duplicate events by logging event IDs, and events not being delivered in order (docs.stripe.com/webhooks).
• Stripe documentation: Fulfill orders, on webhooks being required because customers may not reach the landing page, and fulfillment functions being safe to run more than once (docs.stripe.com/checkout/fulfillment).