The AI prototype iceberg: is your MVP production ready?
A prompt becomes a screen. A few more become a workflow. By the end of the afternoon the application is clickable, demo-ready, and someone says it: the software is almost finished.
What exists is a prototype. That is not a criticism — prototypes validate ideas and cost a fraction of what they used to. The problem starts when the demo is mistaken for the system. AI changed how fast software gets implemented. It did not remove the engineering that has to sit underneath it.
The demo is the first step of five
A prototype answers four questions. Can the idea be software? Does the workflow make sense? Can users understand the screen? Is the core function useful?
For a local tool that solves one person’s problem, that is enough. The moment software becomes a service — customer accounts, private data, payments, business operations — “does it work?” stops being the question. Does it work under load, does it fail safely, can it recover from data loss, can a user reach only their own records, can a bad release be rolled back, and who is accountable when it breaks. A demo answers none of those.
1. Scope: prototypes only build the happy path
A prototype demonstrates the ideal path: enter data, click, get a result. Production has to answer what happens when that data is missing, invalid, duplicated, delayed, or arrives in the wrong order.
The same gap shows up in user journeys. Registration, login, onboarding and normal use are almost always there. Failed actions, account recovery, cancellation and administrative intervention almost never are.
What this phase produces is a written scope with a boundary around it. We deliver ours at the first milestone, before any production code exists, because a document is the cheapest artifact to argue with.
2. Architecture: the access rule has to live in the database
A feature can look completely correct on screen and still hand one customer’s records to another, because the rule underneath is incomplete.
CVE-2025-48757, published 29 May 2025 with a CVSS score of 9.3, describes “an insufficient database Row-Level Security policy in Lovable through 2025-04-15” that “allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites”. The researcher who reported it found 303 exposed endpoints across 170 generated projects — emails, phone numbers, payment details, API keys.
In the AI-built codebases we assess, this is the first thing we check, and the failure has one recurring shape: the authorization exists in the interface and nowhere else. The button is hidden, the route is guarded, the frontend query filters by user id — and the table underneath answers anybody who asks it directly.
Encryption belongs in the same decision, not in a later hardening pass. If you went looking for Supabase field encryption expecting a per-column switch, there is no longer one: the pgsodium-based Transparent Column Encryption is no longer recommended, has been removed from the dashboard’s table editor, and is heading into deprecation. Vault survives, but Vault is for secrets — API keys, webhook tokens — not for your users’ columns. Field-level encryption is therefore an application decision, and encrypted columns lose ordinary querying: no LIKE, no index, no sort. Cheap to design in, painful to retrofit.
3. Execution: the code arrives fast, two things are missing
AI is genuinely good at implementation: application code, repetitive components, well-defined business logic, migrations, first-pass tests, documentation, refactoring, infrastructure configuration. The bottleneck moved off typing and onto defining the right system.
Fast is not the same as correct. Two omissions show up in nearly every codebase we later assess:
- No automated tests. “Did this break anything?” gets answered in production, and every change becomes a gamble the founder eventually stops taking.
- Secrets in the repository or the client bundle. A
service_rolekey in a frontend build bypasses every access rule above it by design.
We treat AI-assisted development as engineer-led execution: senior engineers define the system, guide the implementation, review the result, and stay responsible for it. The model writes most of the code. It carries none of the responsibility.
4. Operation: deployment is where the work starts
Errors have to be captured automatically or they run for days before anyone notices. Knowing the server is up is not the same as knowing the application works.
Hosting limits are part of this. The Supabase free plan gives you 500 MB of database, 1 GB of file storage, 5 GB of egress and 50,000 monthly active users across two active projects, and it pauses a project after one week of inactivity; Pro starts at $25 per month with 8 GB of disk included, then $0.125 per GB. Read the pause rule for what it says: the free tier is a prototype tier. A paused project is an outage, and the first person to notice will be a customer. One gigabyte of file storage is a few hundred phone photos.
Backups are not recovery. A backup that has never been restored is an assumption, and the moment you need it is a poor moment to test it. Run the drill before you need it: restore into a scratch project, time it, and look at what is missing. That number is your actual recovery position.
The same discipline applies to changes. What we find in AI-built projects is the opposite — schema changes applied straight against production from a chat prompt, no reversible migration, development and production quietly diverging until nobody can say which is correct.
Most platforms also need admin tools no customer ever sees: inspect an account, suspend an abusive user, retry a failed job, read an audit log. Without them every incident becomes a manual database operation — slow, risky, and impossible to audit afterwards.
How much of this do you actually need?
Not every application needs the same level of engineering. A local utility is not a platform holding customer records. The bar rises with money, health, safety, private data, business-critical operations and legal obligations.
Take a payment. It must not merely appear to succeed on screen. What happens when the payment goes through but the confirmation request times out? When the user clicks twice? When the provider sends the same webhook event twice? Retries, idempotency and reconciliation are production-engineering problems, and no amount of interface polish addresses them.
For medical or safety-critical software the bar rises again. “The AI generated it successfully” is not an assurance model.
AI is not the problem
The tools are good, and honest about being good. Lovable will produce a React frontend, a sane Supabase schema, working auth and a live deployment faster than any human team, and the code is readable enough for engineers to take over. What it cannot do is own the boundary between “works when I use it” and “safe when a stranger uses it”. Its answer to the CVE above was a security scanner in version 2.0, which flags whether row-level security is present rather than whether it is correct — an enabled policy that never matches passes the scan. Lovable also disputes the CVE, on the grounds that customers are responsible for protecting their own application data. That is worth reading twice, because it accurately describes where the responsibility sits.
The misconception was never that AI can build software. It can. The misconception is that a working prototype becomes production software because the implementation was fast. AI reduced the cost of producing code. It did not reduce the cost of understanding the domain, designing the architecture, protecting the data, verifying the behaviour, operating the infrastructure and accepting responsibility.
If you already have the prototype and want an honest answer about the rest, our vibe-code rescue assessment is free and ends in a written verdict you can challenge.
