Built with Lovable, Bolt or Cursor? A production checklist for vibe-coded apps

The demo works. A customer signs up, sees a dashboard and pays for a booking. Now sign in as a second customer and try to open the first customer's booking by changing its ID in the request.

That test tells you something the demo couldn't.

This is the checklist I'd use before opening an app built with Lovable, Bolt, Cursor or another AI coding tool to paying users. It applies just as well to conventionally written software. The difference is that a founder may have assembled a whole product before anyone explained how its parts work.

Start with a map of what you already have#

Before asking an AI tool to "make this production ready", write down where the application runs, where its database lives and which services it calls, with the owner of each account and how the app authenticates to it.

A booking app might have a browser interface, a database, an authentication provider, a payment gateway and an email service. Each has its own permissions and failure modes, and a successful click in the browser doesn't prove the others are configured correctly.

If your developer left tomorrow, you should still control these accounts. Export access, repository ownership and deployment access belong in the review before launch.

Test permission boundaries with real requests#

Logging in establishes who a user is. Authorisation decides what that user may do.

Create two ordinary accounts and one staff account in a test environment with dummy data. For every private action, try it as the owner, the other customer, the staff member and a signed-out visitor, for reads and writes alike. A user who can't see another person's record must also be unable to update or delete it.

Hiding a button is only an interface choice; the server or database has to reject the forbidden request. Test the request itself, including a modified record ID and an attempt to assign a record to a different account.

For a Supabase-backed app, inspect the row-level security policies and the database roles each request uses. Supabase warns that administrative secret keys bypass row-level security and must never reach a browser, and its current guidance separates those keys from legacy service_role keys. Check which your project uses. Supabase row-level security.

Turn this into an access matrix a reviewer can inspect. "Users can only access their own data" is an acceptance criterion; four recorded requests with expected outcomes are the evidence.

Inspect secrets, uploads and server actions#

Browser code is visible to its users. Review the built application for credentials meant only for the server, rather than judging by an environment variable's name. Some public keys are designed for the client; administrative keys and payment secrets aren't.

If a secret has leaked, move it and rotate it at the issuing service. Deleting it from the latest file doesn't invalidate copies someone already has.

Uploads need their own check: who can upload, which file types and sizes, and who can download each file. Try a private upload's URL while signed out; a student's document and a public product photo need different rules.

For server actions, test bad input and missing permission together. A valid-looking account ID in a request must not override the identity from the user's session. Keep database credentials out of error responses and payment details out of routine logs.

Make payments survive a repeated event#

Imagine a $10 booking. The gateway accepts the payment, but the customer's browser closes before showing the confirmation. Later the payment notification arrives twice.

The right result is one confirmed booking tied to one payment. That needs a server-side record of the transaction and a way to recognise an event you've already processed; a confirmation screen can provide neither.

Stripe's documentation explicitly describes duplicate delivery, says events aren't guaranteed to arrive in order, and recommends recording processed event IDs. Check your own gateway's documentation for its rules. Stripe webhooks.

Ask the reviewer to demonstrate:

1. The server verifies each notification using the provider's documented method.
2. It checks the expected order, amount, currency and payment state before granting access.
3. A repeated notification creates no extra booking, credit or fulfilment.
4. A payment with no matching booking enters a visible reconciliation process.
5. Staff can find and resolve that payment without editing database rows by hand.

Write down what happens after a cancellation, a refund or an expired booking hold before testing them. The reservation side is covered in preventing double bookings in paid slots.

Review the code with a defined security scope#

Run the scans your platform offers, investigate the findings and record what remains open. Lovable's own documentation says its tools find common issues but can't guarantee complete security, and recommends a professional review for sensitive data or critical functions. Lovable security overview.

A useful finding names the affected feature, the consequence, the fix and how the reviewer checked it. A list of package warnings without an assessment won't tell you whether the launch is blocked.

For a broader review, OWASP's Application Security Verification Standard provides testable requirements. Agree which apply to your app instead of commissioning an undefined "security audit". OWASP ASVS.

An app with public articles and an enquiry form has a different scope from one holding student documents or moving money. Describe the data and business actions when you ask for a quote. Calling it an MVP doesn't change what happens to a customer's payment or private file.

Restore a backup before you need one#

"Backup enabled" tells you a copy exists. It doesn't tell you whether your team can recover the application from it.

Restore a recent backup into an isolated environment and check a representative user, booking and uploaded file. Database backups and file storage may be covered differently, so document both. Time the restore and note how much recent data it would lose.

Whether that is acceptable depends on how much data loss your business can tolerate. Supabase lists daily backups with seven-day retention on its Pro plan and point-in-time recovery separately. Those are service features, not a recovery plan for every part of your app. Supabase pricing and backups.

Write the recovery steps for the person who would follow them, including how to pause writes and reconcile payments the gateway recorded while the app was down.

Give launch failures somewhere to go#

Before launch, deliberately trigger a failed payment notification, an unavailable external API and a denied database request in the test environment. Someone should find each failure without a customer sending a screenshot.

Alerts should lead to an action. If the email service fails, should the app retry, show a pending status or notify staff? Decide how many retries are reasonable and what happens when they stop, so a retry loop can't send unlimited messages or charges.

Set usage limits where services support them, and estimate the cost of normal use plus one plausible misuse. If every request calls a paid AI API, request and response limits are part of the operating budget.

Test with a keyboard, on a narrow phone screen and on a slow connection, and check error states as carefully as success. For personal data collected in India, add the notice, retention and rights workflows from our DPDP engineering checklist.

Choose a launch decision you can defend#

Keep the evidence against the release you intend to ship; a permission test from last week may be obsolete after an authentication change.

I'd pause a paid launch for unresolved cross-account access, exposed administrative credentials, an unverified payment path or a recovery process nobody has run. Cosmetic issues can wait. Write the distinction down and assign the remaining work.

A limited pilot reduces how many customers are affected while you watch operations, but it doesn't replace the permission and payment checks. Tell pilot users how to get help, monitor the important actions and keep a way to stop accepting new transactions.

If your app needs an independent review, send us its main customer workflow, stack and launch date. We'll scope the review around the requests, data and transactions that matter. A read-only repository and a test environment are good starting points; customer credentials should not be shared in an enquiry.

Sources#

Checked 4 October 2026.

• Supabase, row-level security and pricing and backups.
• Stripe, webhooks: signatures, duplicate events and delivery order.
• Lovable, security overview: the limits of automated checks.
• OWASP, Application Security Verification Standard.
• Related reading: does AI speed up software development?