An AI-built app is ready for production only when you have evidence that it can survive more than the happy path.
A polished Lovable, Codex, Replit or Bolt demo proves that a flow can work. Production asks harder questions: What happens when User A requests User B’s data? When a payment webhook arrives twice? When a private file URL is shared? When a migration fails? When the person who built the app is unavailable?
Before real users, payments or sensitive data arrive, check seven things:
- Access control: can every user reach only the data and actions they are allowed to use?
- Data integrity: does the system stay correct when requests fail, repeat or arrive out of order?
- Payments and entitlements: can payments be verified and retried without duplicate fulfilment?
- Secrets and generated code: do you know what credentials, dependencies and privileged paths the app contains?
- Deployment and rollback: can you identify what is live and reverse a bad release?
- Testing and monitoring: have you tested failure states, and will production failures become visible?
- Ownership: do you control the code, data, accounts, domain and knowledge needed to operate the product?
I use AI-assisted development because it compresses execution. It does not remove the production bar.
Is a Lovable app production-ready?
It can be. “Built with Lovable” is neither proof of safety nor a reason to rewrite the app.
The right production bar depends on consequence. A public calculator with no accounts has a different risk profile from a multi-user SaaS product handling customer records, payments, private documents and admin actions.
For a serious AI-built product, I would want evidence for authorization, failure handling, secret management, payment integrity, reproducible deployment, recovery, monitoring and ownership. The useful question is not “was AI used?” It is “what has actually been verified?”
1. Check access control beyond the interface
A hidden admin button is not authorization.
For every important resource, write down who can read, create, update and delete it. Then test the denied cases, not only the successful ones.
If you use Supabase from the frontend, understand the security boundary. Supabase’s current data-security guidance says frontend apps can use the Data API with a publishable key when exposed tables have appropriate Row Level Security and least-privilege access policies. Secret and service-role keys are different: they are privileged and must remain server-side.
That means seeing a Supabase publishable key, or a legacy anon key, in browser code is not by itself proof of a leak. The real question is what that client is authorized to do.
Run tests such as:
| Test | Expected result |
|---|---|
| Logged-out visitor requests a private record | Denied |
| User A requests User B’s record | Denied |
| User A changes User B’s record | Denied |
| Manager accesses a record inside assigned scope | Allowed |
| Manager accesses a record outside assigned scope | Denied |
| Admin performs a privileged action | Allowed and auditable |
Do not stop at database tables: test Storage too
A production-readiness review that checks database RLS but ignores uploaded files is incomplete.
Supabase Storage access control uses RLS policies on storage.objects. Private buckets apply access control to downloads; public buckets make retrieval public to anyone with the asset URL. Supabase’s bucket documentation recommends private buckets for sensitive documents and supports authenticated downloads or time-limited signed URLs.
For every bucket, ask:
- Is it intentionally public or private?
- Can User A list or download User B’s files?
- Who can upload, overwrite, move and delete objects?
- Are file-size and MIME-type restrictions appropriate?
- Does a signed URL expire as expected?
- Is the application relying on a filename or folder prefix as if it were authorization?
Ownership metadata alone is not access control. Supabase explicitly notes that object ownership must still be enforced through policies or trusted server logic.
Finally, run Supabase’s Security Advisor. It can flag issues including RLS disabled on exposed tables, permissive policies, sensitive columns exposed and public buckets that allow listing. Treat an advisor result as a finding to investigate, not a certificate that the application is secure.
2. Check what happens to data when something goes wrong
Production users double-click. Networks time out. Jobs retry. Two requests arrive together. A user closes a tab after submitting but before seeing confirmation.
Identify the facts that must always remain true, then enforce them at the right layer.
For example, one invitation should not create two memberships. One payment should not create two credits. A record that must be unique should not depend on a disabled button to remain unique.
Use database constraints, transactions, uniqueness rules, explicit state transitions and server-side validation where appropriate.
Then ask the recovery question: if a deployment writes bad data, what can we restore, and how far back? Supabase’s current production checklist treats security, expected load, availability and recovery as launch concerns. A backup is useful; a recovery path you understand is better.
3. Check payments, webhooks and duplicate fulfilment
A success page is not the source of truth for money.
If the app accepts payments or grants paid entitlements, test:
- server-side transaction verification;
- webhook signature/origin verification;
- duplicate webhook delivery;
- retries after timeouts;
- refreshes of the success page;
- refunds and reversals;
- the case where payment succeeds but fulfilment initially fails.
Stripe’s webhook documentation and Paystack’s webhook and verification guidance all reflect the same operational reality: payment events are asynchronous and may be retried.
The production rule is simple: the same verified transaction arriving again must not create a second business outcome.
4. Check secrets, dependencies and generated code
Generated code is still code you are shipping.
Review API credentials, environment variables, privileged endpoints, third-party packages, file uploads, input validation, CORS/rate limiting where relevant, and logs that may contain sensitive information.
Supabase is moving from legacy anon and service_role keys toward publishable and secret keys. Publishable keys are designed for client code but depend on your authorization model. Secret and service-role keys carry elevated authority and must stay in trusted backend components. See Supabase’s API key documentation.
The important distinction is authority, not whether a value happens to be called an API key.
AI can help inspect a repository, trace data flow and propose fixes. But “the agent says it is secure” is not acceptance evidence. Run the tests, inspect the policies and verify the deployed behavior.
5. Check that deployment is boring and reversible
You should know:
- which repository and branch are the source of truth;
- which commit is live;
- how production environment variables are managed;
- how database migrations reach production;
- what checks run before deployment;
- how to roll back application code;
- what happens when code rolls back but a migration cannot;
- who can deploy;
- who controls the domain and DNS.
As risk grows, stop using production as the scratchpad. Separate experiments from real customer data.
GitHub environments can restrict deployment branches and access to environment-specific secrets. See GitHub deployment environments.
If another developer needs to take over a Lovable product, my Lovable developer handoff guide covers repository, backend, domain, secrets and deployment ownership.
6. Test the journeys AI demos usually skip
Do not finish testing when the main button works.
Try a new account with no data, an expired session, a second user attempting cross-account access, bad input, a duplicate click, slow mobile data, a failed payment, a repeated webhook, an unavailable external API, an oversized file, keyboard-only navigation, and refreshing halfway through a process.
Then make failures observable. Decide where you will see application errors, authentication failures, payment/webhook failures, background-job failures and important administrative changes.
A production failure you can trace is easier to fix than one customers must screenshot for you.
7. Check who owns the product after launch
Ask who controls the GitHub repository, database, hosting, payment gateway, email provider, domain registrar, DNS, analytics, monitoring, secrets, backups and billing.
Then ask the harder question:
If the person or tool that built this disappears tomorrow, can someone competent understand and operate the product?
Document how to run and deploy the app, required environment variables, major external services, migrations, webhooks or scheduled jobs, important business rules and known shortcuts.
Ownership is not only legal ownership of source code. It is operational control.
A practical go/no-go checklist
| Area | Evidence I would want before “go” |
|---|---|
| Access | Allowed and denied role tests pass against database/API behavior |
| Storage | Private files remain private; bucket and object policies match the product rules |
| Data | Critical invariants, migrations and recovery path are understood |
| Payments | Verification and duplicate-event handling are tested |
| Security | Security Advisor reviewed; privileged secrets stay server-side |
| Deployment | Source of truth, environments, deploy checks and rollback are known |
| Reliability | Critical journeys are tested under failure and errors are observable |
| Ownership | Code, data, domain, accounts and operating knowledge are controlled |
You do not need a giant engineering organisation to pass these checks. You do need someone willing to make the release decision from evidence rather than the excitement of seeing the first version work.
When deeper engineering review is worth it
Raise the bar when the product handles private customer records, money, multi-tenant data, sensitive documents, complex permissions, important business operations or automated actions with real consequences.
In those cases, test authorization from a second account, inspect Storage separately from database tables, verify payment idempotency, rehearse recovery and review the deployed system rather than only the generated source.
That is the difference between generating an app and taking responsibility for a product.
If you are still choosing a tool, read my Lovable vs Bubble vs Webflow vs WordPress guide. If the question is budget, see my MVP development cost guide.
If you already have an AI-built MVP and need to decide whether to ship it, harden it, refactor it or rebuild parts of it, see my MVP development service or contact me.