When should you bring in a developer for an app you built with AI?

App builders such as Lovable, Bolt, Replit and Base44 let you go from an idea to a working app in an afternoon, without writing code yourself. That is a real achievement, and for many projects it is enough. The question is not whether AI-built apps are "allowed" to go live; it is how much is at stake if something in the code is wrong, and whether anyone has looked.

The UK's National Cyber Security Centre (NCSC) offered a useful way to think about this in June 2026. It describes AI-assisted coding as a spectrum. At one end, a person writes the code and the AI only suggests the next line. At the other, "full vibe coding," the AI decides the architecture, code and tests while the person just tries the result and prompts again. Neither end is wrong. The point is to slide toward more human control as the risk goes up.

Where does your app sit?

The NCSC's guidance translates into a simple rule of thumb. Fully AI-built is reasonable for prototypes, demos to explain an idea, and internal tools with limited exposure and no sensitive data. Move toward human review when the code handles login or permissions, sensitive personal data, secrets such as API keys, or anything where a flaw would have serious consequences.

"Developer" here doesn't have to mean a full-time hire. A few hours of review by someone experienced with your stack (the platform, database and language your app uses) can catch the problems that matter most. Ask for a written list of findings, so you can have the AI fix them and the reviewer can check the fixes.

What goes wrong when nobody looks

Two cases from this year show the gap between "it works" and "it's safe."

Moltbook, a social network for AI agents whose founder said he had written none of its code himself, had its database key in the site's JavaScript with no row-level security behind it. Row-level security is a set of database rules that limit each user to their own rows. Without it, the security firm Wiz found that anyone could read and change the production data, including about 1.5 million agent API tokens and some 35,000 email addresses. The app worked fine for its users; the missing rule was invisible until someone checked.

Lovable, one of the best-known app builders, published an account of an incident in which, from February 3 to April 20, 2026, the code and build conversations of projects marked public could be read by any logged-in Lovable user with the link. Lovable says private projects and its Lovable Cloud backend were not affected, and it fixed the problem within two hours of a public report. One lesson for builders is a setting many people misread: Lovable separates project visibility (who can see your editor, code and build chat) from website access (who can visit the published app). Many users thought "public" meant only the website.

What should you check before real users arrive?

Run through this list before launch, and again after any large change. Each item can be checked with the platform's settings, a second AI review, or a short session with a developer.

1. Project privacy. Your project, code and build chats are private, not just your published site.
2. Database access rules. Row-level security (or the platform's equivalent) is turned on for every table, and you have tested it: log in as user A and confirm you can't see user B's data.
3. Secrets. No API keys, passwords or admin keys appear in front-end code or in the repository. Keys that must be in the browser are the public kind and are restricted.
4. Login and permissions. Checks happen on the server, not only in the browser. Admin pages refuse ordinary users.
5. Personal data. You collect only what you need, you know where it is stored, and you have a privacy notice that matches what the app actually does.
6. Backups and an exit. You can export the database and the code, and you have restored a backup at least once.
7. The platform's own security scan. If your builder offers one, run it and fix what it reports.
8. A plan for problems. You know how to take the app offline, rotate keys and tell users if something leaks.

You can use the AI that built the app for a first pass:

Act as a security reviewer for this app before it goes live to real users.
For each item, tell me whether it passes, fails or can't be checked from the code, and show me the evidence:
1. Every database table has access rules so users can only read and change their own rows.
2. No secret keys appear in browser code or in the repository.
3. Login and admin checks happen on the server.
4. Personal data collected, where it is stored, and who can read it.
Do not change anything yet. Give me the list first.

Treat its answer as a starting point, not a sign-off. For anything in the bottom two rows of the table above, have a person who reads code confirm the fixes.