Is your vibe-coded app ready for real users?

Conceptual illustration, not a customer photograph.

Before admitting real users to a vibe-coded app, gather evidence that its important behaviours work, that someone can recover it from failure and that the team can support its promises. A working demo or an automated scan covers only part of that decision. The checks you need depend on what could happen when the app gets something wrong.

Choose the launch you are actually preparing for

Work out what a mistake could cost before choosing the checks. A public calculator that holds no personal data presents different risks from a paid booking service. Record the intended users and stored records, then review the promises on the landing page. If you advertise private workspaces, you need evidence that one user's information stays separate from another's.

Set the scope of the release: a capped pilot with direct support, or open access. A smaller pilot still requires protection for its users' data. Keep using synthetic records until someone has reviewed access rules. Healthcare, financial decisions and other high-impact uses need specialist review before people are exposed to the system.

Test permissions with more than one account

Try the same actions through two ordinary test accounts and an administrator account. Include opening a previously saved link after signing out. Removing a button from view does not prevent an unauthorised request. Lovable's security guidance calls for enforcement on the server, protection of secrets and tests of database access policies.

Imagine a client portal where Alice and Bob each have an invoice. Alice should be able to open hers, but changing the address must not let her read Bob's. Repeat the checks for uploaded files as well as database records. For each attempt, record the expected and actual results and the tested version. Bug reports and prompts should contain no real customer information.

Fix access failures before admitting more users. When the team cannot explain why a request succeeds or is refused, find a reviewer who can. A plausible login screen is insufficient evidence; the review needs to establish where access is enforced and whether that boundary holds.

Exercise the payment and failure paths

Build duplicate handling into fulfilment: Stripe's webhook documentation explains that an event can arrive more than once. In a sandbox, exercise successful, rejected and cancelled payments, then send a repeated event. Check the application's response as well as the payment response.

For a booking service, a retry should leave one booking, and a failed payment should leave the paid service locked. Try closing the browser before the confirmation page appears, too. You should be able to reconcile the application's records with the payment provider's records regardless of whether the customer saw that page.

Interrupt the normal flow with a slow network, an unavailable external service or invalid input. The resulting message should explain what happened and what the user can do. Never show success for a failed operation. Put a support contact near the task so someone who gets stuck can find help.

Prove that recovery works

Check exactly what your backup includes. Supabase's documentation says database backups exclude the actual objects held through its Storage API. An app that relies on uploaded images or documents therefore needs a recovery plan for those files as well as its database.

Restore a test copy somewhere isolated from production. Inspect a representative record and its linked file, including the permissions on each. Note the elapsed recovery time and any manual work needed to make the copy usable. Leave production untouched during the rehearsal.

Plan code rollback separately from data recovery. Reverting an interface will not necessarily undo a database change, and it cannot automatically reverse a processed payment. Before a risky release, identify the action that would contain further damage and name the person authorised to take it.

Make the release decision explicit

• Core task: an unfamiliar user completes it without coaching.
• Access: one ordinary user cannot view or alter another's private records.
• Money: sandbox payments, including duplicate events, have the expected effects.
• Recovery: the test restore recovers all required records and files.
• Operation: error reporting and the support queue have an assigned owner.
• Limits: usage caps and known restrictions match the promises made to customers.

Use the checklist to organise evidence, not to claim security certification. Store the results and unresolved problems with the release record. If the team could not respond adequately to a feature's failure, narrow its scope or postpone it until that changes.

Authentication, billing and data-handling changes call for fresh checks after launch. The maintenance guide helps establish that routine; the cost worksheet covers usage and support planning. Finding customers is another task, covered in the first-customer guide.

A worksheet you can reuse

App and version: [ ]
Reviewer and date: [ ]
Test environment: [ ]
Behaviour and test role: [ ]
Expected result: [ ]
Actual result: [ ]
Redacted evidence: [ ]
Result: pass / fail / blocked
Owner and next action: [ ]
Release decision and approved scope: [ ]
Rollback and recovery instructions: [ ]