Your AI-built prototype works. Check these six things before customers log in

A working prototype used to take weeks. Now a founder or an operations manager can describe an app to an AI builder and click through real screens the same day. That is a good thing: a prototype answers questions a document never will. The trouble starts when the prototype quietly becomes the product, with real customers and real data, and nobody has looked at what sits behind the screens.

What the research keeps finding

Veracode tested more than 100 language models on 80 coding tasks in 2025. When a task could be done safely or unsafely, the models picked the unsafe way in 45% of cases. Defences against cross-site scripting failed 86% of the time and against log injection 88% (Veracode). The models got better at writing code that runs; they did not get better at writing code that is safe.

Live apps show the same thing. Escape scanned publicly reachable apps built on Lovable, Bolt.new and similar platforms and reported more than 2,000 highly critical vulnerabilities, over 400 exposed secrets and 175 cases of exposed personal data, including financial details (Escape). A separate scan of 1,645 apps from Lovable's public showcase found about 170 where database tables could be read or written by anyone holding the public key that ships in the browser, because row-level security had never been switched on. It was filed as CVE-2025-48757 with a CVSS score of 9.3 (CVE record; Superblocks).

Keys are the other leak. GitGuardian counted 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34% in a year, and found that commits co-written with an AI coding assistant leaked secrets at roughly twice the baseline rate, 3.2% against 1.5% (GitGuardian).

None of this means AI builders are a bad idea. It means the prototype and the product are different things, and the gap between them is mostly the same handful of checks.

Six checks before real users arrive

1. Every table has an access rule

If the app talks to its database straight from the browser (Supabase, Firebase and similar), open the database console and look at each table. Row-level security, or its equivalent, should be on, with a rule that says who may read and who may write. Then test it the way an attacker would: sign in as user A and try to load user B's record by changing an ID in the request. If it loads, the screens were the only thing keeping data private.

2. No secret sits in the browser or the repository

Search the code and the built JavaScript for strings that look like keys: payment keys, email-service keys, AI API keys. Anything that can spend money or send mail belongs on a server, read from an environment variable. If a key was ever committed, treat it as public: rotate it first, then remove it.

3. The server checks what the screen already checks

A form that refuses an empty email is helpful; a server that refuses it is protection. Every action that changes data should check, on the server, that the user is signed in, owns the record and sent sensible values. AI-written code often does the first and skips the second.

4. Sign-up, password reset and payment have limits

Any endpoint that sends an email, creates an account or starts a payment needs a rate limit. Without one, a script can send thousands of reset emails in your name or run stolen-card tests through your checkout, and the bill arrives before the alert does.

5. There is a backup you have actually restored

Prototypes rarely have one. Turn on daily backups, then restore one into a scratch database and point the app at it. A backup that has never been restored is a hope, not a plan.

6. Someone owns the code

Ask where the code lives, who can deploy it and what happens if the builder's platform changes its pricing or drops a feature. Export the repository to an account you control. If nobody on the team can read it, budget a few hours of a developer's time to walk through it with you; that review costs far less than the first incident.

Keep the speed, add the floor

The point of a fast prototype is to learn cheaply which version of the idea people want. That stays true. For a small app the six checks above take a day or two, and they are the difference between a demo that impressed a client and a product that can hold a client's data. It is the same pattern we described in how businesses are coping with AI in 2026: the tool is quick, and the returns come from the process built around it.

Our own 4-hour prototype works this way: we collect the requirements, build working code with you and hand over the codebase the same day, with access rules in place and keys kept on the server from the start, so the prototype can grow into the product without a rewrite.

Sources

Veracode, 2025 GenAI Code Security Report (press release, July 2025); Escape, The State of Security of Vibe Coded Apps; CVE-2025-48757; Superblocks, Lovable vulnerability explained; GitGuardian, State of Secrets Sprawl 2026; Cloud Security Alliance, research note on AI-generated code security.