Is Your AI-Built App Production Ready?
The 90/65 Rule: Is Your AI-Built App Actually Production Ready?
Understanding This New Unprecedented Power
In late January 2026, a founder launched a social network for AI agents called Moltbook. You may have heard of it, as word spread about it rapidly through social media and viral agent-to-agent interactions. Moltbook’s Founder shared publicly that he hadn’t written one line of the platform’s code himself. Three days later, security researchers at Wiz found the entire production database sitting open: 1.5 million API authentication tokens, 35,000 email addresses, and thousands of private messages between agents. The cause was a single missing setting. Row Level Security had never been enabled on the Supabase database, and the API key was sitting in client-side JavaScript where anyone could read it.
The code worked. It shipped. It went viral. It did exactly what ḩe asked it to do.
It just wasn’t ready, not really, not for primetime. And nothing in how he built it was designed to tell him the difference between functional prototype and production-ready software.
If you’ve built something in Lovable, Replit, Bolt, Base44, or another AI-powered development resource, and it feels like you’re 90% done, the odds are that your gap to production-ready is a bit larger than 10%. When we open AI-built codebases and run production-readiness reviews, the true proportion of production-readiness usually lands closer to 65%.
That’s the 90/65 Rule. It’s our rule of thumb rather than a study. But the gap it describes is growing in recognition right now, and emerging research suggests we’re being generous.
What the 90/65 rule means
90% product completion is what the app feels like from the inside. You’ve used it. Your co-founder has used it. It does the thing. Maybe somebody even paid for it. And maybe you haven’t even received any feedback that it’s not working well.
65% product completion, however, is often the reality when somebody who does this for a living opens the repository.
The 35% gap between written code and production-ready product is often work nobody scoped, because scoping it requires knowing it exists. It isn’t just polish, nor even a final coat of paint.
Why the number isn’t arbitrary
This isn’t a new development unique to vibe coding. In September 1985, Jon Bentley’s Programming Pearls column in Communications of the ACM published a line from his Bell Labs colleague Tom Cargill: the first 90 percent of the code accounts for the first 90 percent of the development time, and the remaining 10 percent accounts for the other 90 percent. It adds up to 180%.
That’s the joke, and it’s also the point.
Veracode’s Spring 2026 study puts numbers on the AI version. Its testing found AI coding assistants now exceed 95% syntax correctness, while security pass rates sit at roughly 55%, effectively unchanged over two years. So the part you can see, that it runs and compiles and looks finished, is at 95%. The part you can’t see is at 55%.
“It works” and “it’s ready” are two different tests
When presenting your app to a potential user, you may provide a demo experience for them. The demo test tells you whether the app runs for one person who knows the happy path, on clean data, doing one thing at a time.
However, a true test of production-readiness asks harder questions: Does it hold up for a new user who doesn’t know what to click? For a confused user? What does it do with bad data? Real money? What happens with two hundred users at once on a Tuesday morning?
Vibe coding tools are very good at the first test. They were built for it. We constantly hear variants of the below:
“It works, mostly. I just don’t trust it under real load.”
“I built this myself, but I’m not a security person.”
They’re the sound of somebody who has passed the demo test and senses, without being able to name why they haven’t passed the other one.
What’s actually in the 35%
The missing work tends to live in one of the below six categories:
On security, the published figures land in a wide range, and the range itself is informative. AppSec Santa tested 534 AI-generated code samples across six models against the OWASP Top 10 in 2026 and found confirmed vulnerabilities in 25.1% of them.
OX Security reports that 62% of AI-built applications ship with critical vulnerabilities.
The difference is definitional: one counts confirmed findings in isolated snippets, the other counts critical issues across whole applications, which is where configuration and access-control failures live. Moltbook’s problem was the second kind, and no snippet-level scan would have caught it.
Your app built in Claude Code, Replit, or other vibe code platform likely sits somewhere in that range. Right now you don’t know where.
We’ve written about the mechanics of this in more depth in our Vibe Coding Risks piece. That post covers the risks you need to be aware of in more detail.
How many users can your app actually handle?
Many non-technical founders can’t answer this, and that’s okay when you’re just testing things out. It’s not okay when you’re trying to scale. At that point, you need specificity.
No general hopes that “it should scale fine.” You need confidence and precision.
“The platform runs comfortably at 300 concurrent users, starts struggling at 800, and falls over at 1,100 because the database runs out of connections.”
That breaking point already exists in your app, whether you’ve found it or not. The only question is whether you discover it in a controlled test or on the morning your launch post takes off.
These patterns are easy to write and expensive to discover. And AI-generated code produces them all the time because they work perfectly at demo scale.
A load test can give you the answer in an afternoon. Two answers, actually: how much load your app can handle comfortably, and where things start breaking.
Once you know both, scalability stops being a worry and becomes a number you can plan around.
How to tell where you actually stand
Ten questions. You can answer these in an afternoon, without hiring anybody.
- Where are your API keys and database credentials stored?
- Has anyone other than you or an AI reviewed this code for security?
- Can a regular user reach data belonging to another user, or to an admin? Have you tested that, or do you assume it’s fine?
- What happens when 200 people use the app at the same time? Have you tried?
- If the app goes down at 2 am, who finds out, and how?
- Can you ship a change and roll it back if it breaks, or is your recovery plan to fix it live?
- Do you have backups of production data, and have you ever restored from one?
- What did your AI and infrastructure costs look like last month, against the month before?
- Which third-party systems does the app need to talk to, and are all of them working end to end?
- After launch, who is responsible for keeping things running? Name the person.
Three or more blanks and you’re not at 90%. That’s not a judgment on what you built, but nobody has looked closely enough yet to confirm your product’s completion, and a system nobody has looked at is unknown rather than fine.
If that’s roughly where you landed, a short call will tell you more than another week of guessing.
How long closing the gap actually takes
The gap from functional prototype to production ready takes longer than a sprint, but often faster than you might think, and the pattern shows up well beyond vibe coding.
Delivery estimates rely on a handful of variables rather than one number, which is why anyone quoting you a figure before looking at the code is guessing.
What moves your timeline:
- How much of your data model survives contact with real requirements
- Number of live integrations
- Whether real user data already exists (migration risk changes the shape of everything)
- How large the security surface is
- Whether maintenance post-production will lie with you or your developer
Should you rewrite it or fix it?
Fix it, almost always.
The instinct to start clean is understandable and usually wrong. Your prototype is a working specification of what the business actually needs, written in the most expensive way there is: by finding out. Throw it away, and you pay for that discovery twice.
Rewrites earn their keep in one situation. When the data model is wrong, when the shape of your data can’t support what the product has to do, no amount of hardening fixes it, and everything built on top has to move anyway.
Ugly code is a different problem with a different answer. Ugly code gets refactored. Worth having somebody tell you which one you have before you decide.
Common questions
How do I know if my vibe coded app is production ready?
Run the ten questions above. If three or more come back blank, it isn’t. The reliable signal isn’t whether the app works, it’s whether anyone has deliberately tested security, load, deployment, and recovery. Working is easy to verify. Ready takes someone knowing what to test and look for.
What’s missing from an AI-built app before launch?
Usually six things: a security review, a deployment and rollback process, monitoring and alerting, integration testing against live systems, a data migration plan, and a named owner for post-launch support. AI coding tools aim for a working result, and none of those six produce one.
Is vibe coded code safe to deploy?
Not without review. AppSec Santa found confirmed vulnerabilities in 25.1% of AI-generated samples tested against the OWASP Top 10 in 2026, and OX Security puts the figure at 62% of AI-built applications shipping with critical issues. The variance between studies is large. The direction is consistent.
How much does it cost to make an AI vibe-coded app production-ready?
It depends on how much of your data model survives, how many live integrations exist, whether real user data is already in play, and who will own the app afterward. Anyone quoting a number before reviewing the codebase is guessing. An honest first conversation costs nothing and narrows the range considerably.
Should I rewrite or fix my vibe coded app?
Fix it, unless the data model is wrong. Your prototype is a working specification of what the product needs, and a rewrite discards that. Rewrites make sense when the underlying data structure can’t carry the product’s requirements. Ugly code gets refactored, not replaced.
Who fixes vibe-coded apps?
Development teams that specialize in production hardening rather than greenfield builds. What you want is somebody who audits before quoting, takes ownership of security and deployment, and stays on after launch. The quality of the handoff matters more than the hourly rate.
What founders in this position actually need
Nobody at this stage needs somebody to finish typing the code. You have the code.
What’s missing is somebody to take the handoff: to own security, deployment, scale, and the 2 am pager, and to carry the part of the journey you were never trained for. The hard thing about sitting at 65% is that the remaining work is all the work you never signed up to be responsible for.
That’s the moment Rubico exists for. We’ve called it The Wall, the point where the speed of vibe coding meets the structural demands of production software. Every project that gets far enough to matter arrives there eventually.
If you’re standing at it, let’s talk about where your app actually is. Twenty minutes, no quote and no pitch, just an honest read on the gap and what closing it looks like.
