What I check in a vibe-coded app before launch

Why apps built with AI tools need a second look

Tools like Lovable, Bolt, Cursor and Replit are very good at what you ask them for. Describe a screen, a sign-up flow or a dashboard, and you get one that works. That is exactly why they are a smart way to find out whether anyone wants your product.

The gaps sit in the things nobody puts in a prompt. Nobody asks for "make sure customer A can never see customer B's invoices" or "keep a copy of the database somewhere safe". The app looks finished, the demo goes well, and the parts that protect real users are missing or only half there.

None of this is unique to AI tools. Broken access control tops OWASP's 2025 list of web application security risks, a list that covers software of every kind. The difference is speed: when you build in days, the checks a team would normally make along the way can be skipped entirely.

Source: OWASP Top 10:2025 (opens in a new tab), correct as of 5 October 2026.

So I do not start with the code quality. I start with five questions about what could hurt your users or your business on day one.

The five things I check first

Secret keys in the wrong place

Most apps talk to other services: a database, a payment provider, an AI model, an email sender. Each one gives you keys. Some are designed to sit in the app people download or load in their browser. Others are secret and must only ever live on a server.

The providers are clear about this. Supabase says of its secret keys: "Never put one in a browser, a shipped application, or source control." Stripe says only publishable keys are safe to expose outside your application's backend. OpenAI warns that a key in a browser or mobile app lets someone "make requests on your behalf", which "may lead to unexpected charges or compromise of certain account data".

Source: Supabase, API keys (opens in a new tab), correct as of 5 October 2026. Source: Stripe, API keys (opens in a new tab), correct as of 5 October 2026. Source: OpenAI, Best practices for API key safety (opens in a new tab), correct as of 5 October 2026.

What I check: whether any secret key appears in the front end, in the code repository, or in the repository's history. If one has been exposed, deleting it from the code is not enough. OWASP's advice is that exposed keys should be revoked immediately and replaced, then removed from wherever they were found.

Source: OWASP, Secrets Management Cheat Sheet (opens in a new tab), correct as of 5 October 2026.

Access rules that only exist on the screen

Hiding a button is not access control. If the only thing stopping a user from seeing someone else's data is that the app does not show them a link to it, the data is not protected. OWASP's examples include viewing or editing someone else's account by changing its identifier, and APIs that accept changes without checking who is asking.

Source: OWASP, A01:2025 Broken Access Control (opens in a new tab), correct as of 5 October 2026.

If your app keeps its data in Supabase, the rules live in the database as Row Level Security. Supabase's own guidance is to "enable RLS on every table in an exposed schema", because a table without it "is readable and writable by any role with a grant on it".

Source: Supabase, Row Level Security (opens in a new tab), correct as of 5 October 2026.

What I check: I create two ordinary user accounts and try to reach one account's data from the other, through the app and directly through its API. It takes an afternoon, and it is the single most useful test I know for an app that holds customer data.

One environment for everything

When there is only one copy of the app, every change is tested on real users. A prompt that "just fixes the layout" can break sign-up for everyone, and there is nowhere to try it first.

A separate test environment, with its own database and its own test keys, fixes that. Most services support it already. Stripe, for example, gives you a sandbox with its own keys, where objects in one mode are not accessible in the other. Real customer data stays in live, and test data stays out of it.

Source: Stripe, Sandbox versus live mode (opens in a new tab), correct as of 5 October 2026.

What I check: whether there is a test environment at all, whether it uses real customer data, and whether a change can be tried there before it reaches users.

Backups nobody has restored

A database without backups is one bad prompt or one deleted table away from losing your business. A backup nobody has restored is a hope rather than a plan.

The NCSC's advice to small organisations is to back up all the data your business needs to operate, and once you have made your backup, to know how to restore it and check that it contains all your important data.

Source: NCSC, Backing up your data (opens in a new tab), correct as of 5 October 2026.

What I check: what is backed up, how often, where the copies are kept, how long they are kept for, and whether anyone has restored one into a test environment and checked it.

Nobody would know if it broke

Apps fail quietly. A payment webhook stops firing, sign-ups start erroring, a background job falls over. Without monitoring, the first person to notice is a customer, and often they simply leave.

Security logging and alerting failures are on OWASP's 2025 list for the same reason: problems you cannot see, you cannot fix. There is a legal side too. If personal data is exposed, UK GDPR says you must tell the Information Commissioner without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to people. You cannot meet that deadline for a breach you have not noticed.

Source: UK GDPR, Article 33 (opens in a new tab), correct as of 5 October 2026.

What I check: whether errors are recorded somewhere a person will see them, whether someone gets an alert when the app goes down, and whether there is a log of who did what with sensitive data.

Rescue or rewrite?

The big question after any review is whether to start again. Usually the answer is no.

Why rescue usually comes first

Everything in the section above can be fixed in place. Keys can be moved and rotated. Access rules can be added table by table. A test environment can be set up alongside the live one. Backups and monitoring can be switched on in days, not months.

The app you have also holds something a rewrite throws away: everything you learned getting it in front of people. The screens, the flows and the copy have been shaped by real reactions. Starting again means rebuilding all of that before you can add anything new.

The signs a rewrite is cheaper

Sometimes the foundations are the problem, and fixing them in place costs more than building again. The signs I look for:

• The data model does not fit the product. If the way data is stored fights what the product needs to do, every new feature is a workaround.
• Access rules cannot be added without touching everything. If every query, every screen and every API call would need changing anyway, you are already doing a rewrite, just slowly.
• You cannot get your code or data out. If the platform holds both and cannot export them, you do not own the thing you are building on.
• Every change breaks something else. With no tests and no structure, each fix creates two new problems.

Decide with a costed plan, not a hunch

The way to decide is to list every finding, rank it by severity, put a cost against fixing each one, and compare the total with the cost of rebuilding, including the time to get back to where you are now. That is what a Product Review ends with.

A long list of findings is not a verdict. On one pre-launch review I ran, there were 152 findings, 2 of them critical and 30 high. All 8 launch blockers were resolved before any real user data was exposed. What mattered was the order they were fixed in. You can read how those launch blockers were caught.

A pre-launch checklist

Not everything has to be perfect on day one. What matters is knowing which items are launch blockers and which can safely wait a few weeks.

Fix before launch

• No secret keys in the app, the code or the code's history, and any key that was exposed has been revoked and replaced.
• Every table and every API checks who is asking, tested with two ordinary user accounts.
• Separate test and live environments, with real customer data only in live.
• Backups running automatically, with one restore tested and checked.
• Admin and hosting accounts protected with multi-factor authentication, and owned by your company rather than one person.
• Someone gets an alert when the app goes down or errors climb.
• You know what personal data you hold, where it lives, and what you would do in the first 72 hours after a breach.

Fix soon after launch

• Automated tests on the paths that take money or hold personal data.
• Dependency updates on a regular schedule. Software supply chain failures are on OWASP's 2025 list too.
• A short written record of how the app is deployed and who has access to what.
• A privacy policy that matches what the app actually does with personal data.
• A look at performance and running costs before you spend on growth.

If you would rather have someone senior go through this with you, a Product Review covers all of it, ranks what it finds, and tells you what to fix first. And if you are still deciding what to build, the questions I ask before writing a line of code is the place to start.