What to check before you launch a vibe coded app

Four tiles headed Before you launch (Secrets, Permissions, Backups, Review), the checks in a vibe coded app review

Quick answer: A vibe coded app can work in every demo and still let one customer see another’s data. Before launch, an independent review checks nine things (secrets, sign-in, permissions, data separation, performance, deployment, monitoring, backups and maintainability) and sorts what it finds into launch blockers and fixes that can wait. Blockers such as a secret key in the front-end bundle, missing access rules and one environment for everything can be fixed without starting again.

Your vibe coded app works, the first customers are about to sign up, and nobody outside the build has read the code. Escape’s research team analysed over 5,600 publicly available apps built on vibe coding platforms and found more than 2,000 vulnerabilities, over 400 exposed secrets and 175 instances of personal information. Escape notes its dataset is heavily skewed toward Lovable apps, which may disproportionately influence the prevalence figures.

Inside an established organisation, a team may have built an app for staff or customers with AI tools. Before that AI-generated app rolls out, someone in IT, privacy or management asks whether it has been reviewed. In both cases the vibe coding risks that decide a launch sit in secrets, sign-in, permissions, data and deployment. This guide sets out the nine checks a review makes, a test for which findings block launch, and the privacy obligations that arrive with real customer data.

A demo never shows the parts of a vibe coded app that fail at launch

A demo exercises one signed-in user, test data and the screens that work. Launch adds strangers, real data, payments and load. Strangers can edit the address bar, reuse an old password reset link and open the browser’s developer tools. Real data puts one customer’s records beside everyone else’s, often in the same database.

Two controls decide whether those strangers can reach that data. The first is access control, which OWASP defines in one sentence. “Access control enforces policy such that users cannot act outside of their intended permissions.” Broken access control holds the #1 place in the OWASP Top 10 2025, and OWASP reports some form of it in 100% of the applications tested for that list.

The second is keeping secrets out of the browser. In the vibe coded apps it analysed, Escape found Supabase service keys “often trivially retrievable from frontend bundles”, the JavaScript files every visitor’s browser downloads. A demo never opens those files, so it cannot show what is in them.

A review of a vibe coded app makes nine checks

A vibe code review makes the same checks as a review of any app about to take real customers, whether people or AI tools wrote the code. Vibe coding security is application security, checked before launch. Each check below says what it looks for and the sign it fails, written as a test you can run or ask your developer to run.

Secrets and keys. It looks for secret keys and passwords anywhere the browser can reach them. Some keys are made to be public, such as a Supabase publishable key, and reach only what the access rules allow. It fails when a secret or service key can be read in the front-end bundle.
Sign-in. It looks at how accounts are created, signed in, reset and signed out. It fails when a password reset link still works after it has been used, or when a session never expires.
Permissions. It looks at who can do what, on every screen and every request. It fails when changing an ID in the address bar, or in a request the app sends, shows another user’s record.
Data separation. It looks at how each customer’s data is kept apart in the database. It fails when one account can read another account’s rows. Where the browser queries the database directly with a public key, as Supabase allows, row level security is the setting that keeps accounts apart, and Escape lists missing row level security among the critical weaknesses in its research.
Performance. It looks at how the app behaves with realistic data and several people using it at once. It fails when the busiest screen slows or times out under that load.
Deployment. It looks at how a change reaches production and how it comes back out. It fails when there is no separate test environment, or nobody can say how to roll back the last release.
Monitoring. It looks at what happens when something goes wrong in production. It fails when an error reaches nobody until a customer reports it.
Backups. It looks at what is backed up, how often and where the copies are kept. It fails when no backup has ever been restored to prove it works.
Maintainability. It looks at whether someone new to the code can understand it and change it. It fails when another developer cannot explain or safely change a core part of the code.

These nine set the scope of the review in this guide, and they are only part of security. A penetration test is a separate exercise by a specialist tester, and dependency scanning, input validation and rate limiting each need their own check.

Which findings should stop a vibe coded app from launching

A long list of findings is hard to act on until it is sorted. A simple test does the first sort, and the person accountable for the launch makes the final call. A finding blocks launch when it does any of these.

Exposes another person’s data.
Lets one user act as another.
Can lose data with no way to restore it.
Leaves the app unable to be redeployed or rolled back.

Everything else is a first-month fix or backlog. A first-month fix matters soon after launch but puts nobody’s data at risk on day one. Backlog makes the app easier to run and change, and waits for a planned release. If the app takes payments, a finding that could change what someone is charged or expose payment details blocks launch too. The sort also depends on the data the app holds. Health records and payment details move findings up the list.

An illustrative ranked list, written as an example for an app that holds customer accounts, looks like this.

Blockers

A secret key can be read in the front-end bundle.
Changing an account ID in the address bar shows another customer’s records.
Test and live share one database, and no restore has been tested.

First-month fixes

Errors in production alert nobody.
The busiest screen slows under realistic load.

Backlog

A core module only one developer can change safely.

A list sorted this way is a decision you can defend to a co-founder, an investor or an IT team. Blockers are fixed before launch, first-month fixes go into the first releases after it, and the backlog waits its turn.

Real customers bring privacy obligations with them

Once real people sign up, the app holds their personal information, and Australian privacy law may apply to it. The Office of the Australian Information Commissioner (OAIC) defines a small business as one with an annual turnover of $3 million or less. Being under that line does not settle the question. Regardless of turnover, the Privacy Act covers some businesses, including health service providers and businesses trading in personal information. For an entity the Act covers, Australian Privacy Principle 11 requires reasonable steps to protect the personal information it holds from misuse, interference and loss, and from unauthorised access, modification or disclosure.

The Notifiable Data Breaches scheme covers any organisation or agency the Privacy Act 1988 covers. It requires notice to affected individuals and the OAIC when a data breach is likely to result in serious harm to an individual whose personal information is involved. That puts secrets, permissions and data separation (checks 1, 3 and 4) at the centre of a launch decision, because a failure in any of them can show one person’s information to another.

Confirm your own position with your adviser.

Fixing a vibe coded app starts with the code you have

Each finding on a ranked list names a specific change, and the blockers in the example above can all be fixed in the app you already have.

Move secret keys to the server, rotate them, and keep them out of the front-end bundle.
Add access rules to every request, and row level security (or your database’s equivalent) to every table that holds customer data.
Separate test and live environments, and make every release one you can roll back.
Send production errors to a named person, with alerts that reach them.
Back up the database and prove a restore works.

Changes like these fix vibe coded app findings before launch without starting again.

Some findings point to one part that needs rebuilding. Two signs are a data model with no way to tell one customer’s records from another’s, and a database schema that cannot be migrated without losing data. Rebuild that part and keep the rest. Scope it the way you would a minimum viable product, by deciding what the first release must do and what can wait. Our platform build for AMillionPaths started the same way, with a focused first release scoped from the client’s patent specification and early prototype.

After launch, someone has to own the code

Launch is the first day of running the app. Deployment, monitoring and backups keep running after it, and our DevOps and hosting page covers how we run them. Security updates to the libraries the app depends on, and regular restore tests, need a named owner, as ongoing support or within your own team.

Since 2008 we have designed and built software, and our secure software development team reviews codebases before launch and fixes what the review finds. We review the code, sign-in and permissions, how each customer’s data is kept apart, and the deployment, monitoring and backups. Send us what the app does, what data it holds, where it is hosted and when you plan to launch. You get a ranked list of what must be fixed before launch, with the evidence for each item. The list is written to stand on its own, and it is yours to act on with any developer.

A demo shows the app works. A review shows whether it is ready for strangers.

Questions about launching a vibe coded app

Is a vibe coded app safe to launch?

It can be, once it has been checked for what a demo never exercises. Before real customers sign up, confirm that no secret key sits in the front-end bundle, that changing an ID never shows another user’s record, that each customer’s data is kept apart, and that you can restore a backup and roll back a release. Fix anything that fails those tests before launch.

How do I know if my vibe coded app is secure?

Start with the tests a reviewer would run first. Search the front-end bundle for secret or service keys. Change an ID in the address bar and see whether another user’s record appears. Sign in as one test account, try to open another account’s data, and check that nothing comes back. Then have someone outside the build read the sign-in, permissions and data rules in the code, which is where vibe coding security is decided.

What do you need access to for a review?

Read access to the code repository, and to the hosting or platform account the app runs on. Together they show the code, the configuration, the environments and how a release reaches production. A short note on what the app does, what data it holds and when you plan to launch helps us rank the findings. We need read access only, and fixes come later, once you have the ranked list.

Can I ask the AI tool to review its own code?

Yes, and it is a useful first pass. Ask it to look for exposed secret keys, missing access rules and unsafe database queries, then fix what it finds. An independent reviewer reads what the tool was never asked about, such as how a release is rolled back, whether a backup restores and whether another developer could change the code safely.

Can a vibe coded app be fixed, or does it need a rebuild?

The fixes for exposed secret keys, missing access rules, a shared test and live environment, and missing monitoring or backups are made in the existing app, without starting again. One part may need rebuilding when its data model has no way to keep customers apart, or its database schema cannot be migrated without losing data. A review tells you which applies, part by part, before you decide.

Does a code review replace a penetration test?

No. A code review reads the code, configuration and deployment from the inside. A penetration test is a separate exercise by a specialist tester, who attacks the running app to find what can be exploited. The two often find different weaknesses, and dependency scanning, input validation and rate limiting each need their own check too. We fix what the review and the test find.

Does a review satisfy an IT security or privacy approval?

A review gives the people who make that decision the ranked list and the evidence they read. It does not certify the app. Formal assessment and certification are done by independent assessors and certification bodies. We do the engineering around them. If your IT, security or privacy team has a set process, share it before the review starts so the list answers its questions.