Production-ready: the checklist a Lovable project has to pass
“It works” and “it is ready” are different claims. This is the gap between them, in the order the failures usually show up.
Most Lovable projects that reach us are not broken. They demo well, the screens look right, the happy path works. What is missing is everything that only appears once other people start using the thing: the second concurrent user, the expired session, the declined card, the phone in portrait mode, the person who hits the back button mid-flow.
The list below is the one we work through before we call a build finished. It is ordered roughly by how often it causes real damage after launch, not by how hard each item is to fix.
1. Access rules enforced in the database, not the interface
This is the single most common serious defect we find. Hiding a button is not access control. If your app talks to Supabase from the browser, anyone can open the network tab, read the anon key and call the same endpoints with their own parameters.
Row Level Security has to be on for every table holding user data, with a policy per operation. The test is simple and worth doing by hand: sign in as user A, capture a request, replay it with user B's session and a row id belonging to A. If you get data back, you do not have access control.
2. Every state a screen can be in
Prototypes are built against data that exists. Real apps spend a surprising amount of time in the other states, and an unhandled one usually renders as a blank panel or a crash.
- Loading — a skeleton or spinner, not a layout that jumps when data lands.
- Empty — the first-run state, with a next action rather than an empty table.
- Error — what failed, and what the person can do about it. Not a raw exception.
- Partial — one widget failed while the rest of the page is fine.
- Unauthorised — the session expired mid-session; say so and offer a way back in.
3. Mobile, tested on a real device
Browser devtools lie about several things that matter: the on-screen keyboard covering a submit button, 100vh under a mobile browser chrome, iOS zooming into inputs with a font size under 16px, and tap targets that are fine with a mouse and hopeless with a thumb.
Check the forms in particular. A signup that cannot be completed one-handed on a phone is a signup that does not happen.
4. Payments, including the paths nobody demos
The Stripe happy path is the easy part. The failure paths are where money and trust get lost:
- The card is declined, or 3-D Secure is required and the customer abandons the challenge.
- The customer closes the tab after paying but before your return page loads.
- The webhook arrives twice — Stripe retries, and your handler must be idempotent.
- The webhook arrives before the browser returns, or not at all for several minutes.
- A delayed method (SEPA direct debit) stays unpaid for days before settling.
The rule that covers most of these: the webhook is the source of truth, not the redirect. Grant access when the webhook confirms payment. The return page should read state, never write it.
5. Secrets that are actually secret
In a Vite-based project every variable prefixed for client exposure ends up in the shipped JavaScript. Anything else has to be read server-side. Before launch, build the project and search the output bundle for the first eight characters of each secret you hold. It takes two minutes and occasionally saves a very bad week.
6. Email that arrives
Password resets and confirmations are part of the product, and they fail quietly. A sending domain needs SPF, DKIM and DMARC records in DNS and time to verify — this is frequently the last blocker before a launch because DNS changes are not instant.
Send one of each transactional email to a Gmail, an Outlook and a corporate address before you believe it works.
7. The legal minimum for a German or EU launch
Not SEO advice and not legal advice, but a launch blocker all the same: a German-facing commercial site needs a reachable imprint and a privacy policy that matches what the product actually does — including which processors touch personal data. If analytics or embedded third parties set cookies that are not strictly necessary, consent has to come before they load, not after.
8. Knowing when it breaks
Without error reporting, your first signal of an outage is a customer who has already given up. You need server and client errors captured with enough context to reproduce them, plus an uptime check on the domain itself. The bar here is low and the payoff is immediate.
9. A handover someone else can act on
Ownership is not a zip file. What the recipient needs is the account inventory — who owns the Lovable project, the repository, the database, the domain, the payment account — plus how to run it locally, how to deploy, where the environment variables live, and what is deliberately not built yet.
That last point matters more than it sounds. Undocumented scope gaps turn into support requests and arguments about what was promised.
How to use this list
Go in order and stop at the first item you cannot demonstrate. Sections 1, 4 and 5 are the ones that cause damage rather than annoyance — if you only have an afternoon, spend it there.
| Area | Typical failure | Severity |
|---|---|---|
| Access rules | Any user can read another user's rows | Critical |
| Secrets | A service key ships in the browser bundle | Critical |
| Payments | Access granted on redirect, not on webhook | High |
| Screen states | Blank panel when a request fails | High |
| Password reset silently never arrives | High | |
| Mobile | Submit button sits under the keyboard | Medium |
| Legal pages | No reachable imprint on a German site | Medium |
| Monitoring | Outages discovered by customers | Medium |
| Handover | Nobody knows which account owns the domain | Medium |
If you would rather have someone else run this pass on your project, that is what our Project Check is: a written diagnosis and a prioritised plan, before you commit to a rebuild. For an agreed set of fixes after the review, see Lovable Rescue.
Frequently asked
- Is a Lovable project production-ready out of the box?
- It gives you a working application quickly, which is genuinely most of the way. What it does not do for you is decide your access rules, your failure paths, your payment edge cases or your legal pages — those are product decisions, and they are what this checklist covers.
- What is the most common serious problem you find?
- Missing or incomplete Row Level Security. The interface hides what a user should not see, but the underlying API will still return it to anyone who asks directly. It is invisible in a demo and severe in production.
- How long does it take to fix these things?
- It depends entirely on how the project is structured. Access rules and payment handling are usually days rather than weeks. A project that has grown without structure can take longer to make safe than to have rebuilt cleanly, which is why we assess before quoting.