Built your app with AI coding tools? What to check before real users arrive

An app built with AI coding tools needs six checks before real users arrive. Put the accounts and code in your name. Move the secrets out of the code. Make sure each user sees only their own data. Keep a backup you can restore. Check it holds up under real use. Then name who looks after it next month.

Vibe coding means building software by describing it to an AI tool and accepting what it writes. The catch is not that such code is always bad. It may be software nobody has read closely, handling customers' data in ways nobody chose.

You can work through most of this yourself. For a second pair of eyes, our support for sites and software someone else built starts with a short review.

Your AI-built app security checklist

This is a first check before launch, not a security audit. Work through it before the first real user, payment or personal record reaches the app.

Accounts and code in your name

Every account the app depends on should be in the business's name, with a business email address. A repository is the online account where the code and its full history are kept. List them before anything else.

• The repository. The code, in an account the business owns.
• Hosting. Where the app runs, and the settings that hold its keys.
• The domain. The registrar account, with auto-renew on.
• The database. Often a separate service, with its own login and its own backups.
• Payments. The payment provider's account, and who receives its alerts.
• Email. The service that sends sign-up and password-reset messages.

If a freelancer or a friend set any of these up, move them now, while everyone is talking. If someone has already gone quiet, start with what to do when your developer left and you can't get in.

Secrets out of the code and its history

Secret keys and passwords belong in the hosting platform's settings, never in the code. A secret is anything that lets software act as you: a payment secret key, a database password, an email-sending key. If one is written into a file, anyone who can read the repository can use it.

Some keys are designed to be public. A payment provider's publishable key, or a database's public client key protected by access rules, is meant to ship with the app. Its safety depends on those rules, so ask which kind each key is.

Deleting the line is not enough, because the repository keeps every earlier version. On GitHub, secret scanning scans the entire Git history on all branches for hardcoded credentials. It runs free on public repositories; for private ones it depends on the plan and settings.

If a secret has been committed, GitHub's guide to removing sensitive data says the first step is to revoke or rotate it. Rewriting the history comes after, and cannot reach other users' clones. So treat any secret key that was ever in the code as exposed, and replace it. Public client keys are the different case described above.

Each user sees only their own data

Access control is the rule that decides who may see or change what. OWASP's 2025 list of web application security risks puts broken access control first.

OWASP says access control enforces policy such that users cannot act outside their intended permissions. One failure it lists, in plain terms: a customer changes a number in the address bar and sees another customer's order.

1. Create two test accountsUse two email addresses you control, and add a little data to each.
2. Open a record as the first accountAn order, a profile or an invoice, and note its address in the browser.
3. Open the same address as the second accountYou should see an error or nothing, never the first account's record.
4. Try the same while logged outPrivate pages should send you to the login screen.
5. Repeat for every kind of recordOrders, files, messages and anything a user can edit or delete.

Passing this test is a good sign, not proof the app is safe. The app's server can still answer a request the screens never make, so the rules have to hold there too.

Some apps keep these rules in the database itself. Supabase, one database platform, uses a Postgres feature called row level security. Its documentation says a table in an exposed schema without it is readable and writable by any role with a grant on it. Whatever the app uses, ask where the rule lives.

Data and backups you have tested

Write down what personal data the app stores, such as names, phone numbers and payment references, and which service holds each. Collect only what the app needs.

Then check the backups. CISA, the US government's cyber defence body, advises smaller businesses to follow the 3-2-1 rule. That is three copies, on two kinds of storage, with one kept off site. It also advises scheduled recovery tests, so restore a copy to a private test version of the app and open it.

Rules on personal data differ by country and by the kind of data. This page is general information, not legal advice; confirm what applies with a lawyer.

It holds up under real use

Real users find the paths a demo never took, so the app should tell you when something fails.

• Errors logged and someone alerted. OWASP says that without logging and monitoring, attacks and breaches cannot be detected. Logs should go to a place a person reads, with access controls and without passwords, secret keys or unnecessary personal data.
• Plain error messages for users. OWASP lists error handling that reveals stack traces or other overly informative error messages to users as a misconfiguration. The detail belongs in the log, not on the screen.
• Slow pages measured. Time the main pages on a phone with real data in them, not the near-empty test version.
• Limits on logins and forms. OWASP advises that you limit or increasingly delay failed login attempts, without locking real users out. Sign-up and contact forms need a similar limit, so a script can't fill them thousands of times.
• No default or test logins. OWASP says not to deploy with default credentials, particularly for admin users. Remove any test admin the tools created.

A slow page is a problem to measure and fix where it is. If someone suggests splitting the app into many small services, read whether your app needs microservices first.

Someone looks after it next month

The app is built from other people's code, called dependencies, and those keep changing. OWASP advises that you continuously monitor public vulnerability databases for flaws in the components you use.

On GitHub, Dependabot alerts notify you about vulnerable dependencies. An alert only helps if someone reads it, applies the update and checks the app still works. What that arrangement should say is in what website maintenance includes, and what to get in writing.

When you can leave it alone

What a review gives you back

A professional review goes further than the checks above. It tests permissions on the server and the API, not only in the browser, including who can edit or delete records and open uploaded files. It also reads how logins, payments and secrets are handled in the code.

It comes back written up, area by area, each marked fine or pending, with a plain next step. Our support page covers sites and software we didn't build. In its words: "We take those on too, after a short review, so we know what we're taking on and can tell you honestly what state it's in."

After the sheet comes "a written support agreement, or a plain answer if it's better rebuilt", in our support page's words. A rebuild is not the default.

Next step: list the accounts the app uses, who holds each, and what data it stores. Tell us what you have, and we'll say what we would review first.

Reviewed and edited by Online Scope before publishing. Something out of date? Tell us at info@onlinescope.in. How we write the Blog.