Vibe coding is real: describe what you want, and Lovable, Bolt, v0, Replit, or Claude builds something that runs. The demo works, the screens look right, and the distance between idea and working software has never been shorter. Then you consider letting strangers use it, maybe pay through it, and a different question appears: what separates this from software a business can rely on. This article is the honest map of that gap, written as the checklist we work through when someone hands us an AI-built app.
Quick answer: Production ready means secrets out of the code, authentication enforced on the server, database rules that deny by default, error tracking, tested backups, hosting and domains under your control, and a way to ship changes without breaking what works. AI builds the features. The last stretch is operations discipline, and it is learnable or hireable.
What does production ready mean?
A working demo answers one question: can the software do the thing. Production readiness answers different ones. When it breaks, will you know before your users tell you? If the database is lost, is yesterday recoverable? Can a stranger with browser dev tools read data they should not? Can you change feature three without silently breaking feature one? None of these are features, which is why they are missing: nobody prompts for them, and the AI optimizes for the thing you asked to see.
Why do AI builders stop at 70 percent?
Because that is what they are for. Research out of Columbia’s DAPLab found vibe coding typically gets you about 70 percent of the way to a working application, and the first draft looks polished. The CEO of Cursor put it more bluntly, telling Fortune that pure vibe coding builds shaky foundations. The tools generate the happy path: what happens when everything goes right. Production is the collection of everything else: bad inputs, double clicks, expired sessions, malicious visitors, and the third-party API being down. That last 30 percent was never in your prompts, so it was never in the code.
What breaks first in production?
The same short list, in roughly this order. Silent errors: something fails, no one is notified, and the app keeps running while quietly losing data or producing wrong results. Authentication gaps: routes and API endpoints that check nothing on the server, protected only by the interface not showing a button. Exposed secrets: API keys sitting in the client bundle or the repo history. Missing backups, discovered at the worst possible moment. And regressions: every new AI-generated change risks breaking old features, because nothing automatically checks that they still work.
What is the production gap checklist?
- Secrets out of the code: keys in environment variables, anything ever committed rotated.
- Authentication and authorization enforced server-side on every route, API endpoint, and function.
- Database rules that deny by default, with row level security enabled and tested.
- Error tracking wired to something that notifies you, so failures stop being silent.
- Backups on a schedule, stored separately, with a restore you have tested once.
- Uptime monitoring on the app and its critical flow, alerting your phone.
- A domain, DNS, and email setup you own and control.
- A deploy process with at least a build check and one smoke test before changes go live.
- An accounts inventory: hosting, database, domain, and repo access documented and owned by you.
Everything on this list is standard work with standard tools. None of it requires rebuilding what the AI made.
Who should do this work?
You can, with time and the checklist above, and the platform docs have improved. The honest constraint is that several items involve judgment calls (security policies, restore procedures, what to monitor) where the first attempt teaches expensive lessons. The alternative is handing the repo to a developer for a production audit: a review of exactly these items with a report of what is solid and what is fragile. Either path beats the default, which is shipping and finding out.
What does it cost to close the gap?
Market ranges for 2026: a production audit runs $500 to $1,000, and hardening work on a typical single-product app lands in the low four figures, more when payments or sensitive data raise the stakes. Compare that against what the app is supposed to earn, or what one data exposure would cost, and the gap work prices itself. It is the cheapest phase of the whole project, and the one most often skipped.
Frequently asked questions
Is vibe coding bad?
No. It compresses the idea-to-prototype phase from months to days, which is a genuine shift. The failure mode is treating a prototype as a product. Building fast and hardening properly are compatible, and the teams doing both are getting the best of it.
Do I need to rewrite the app properly?
Rarely. AI builders output standard React and Node code on standard databases, and standard code can be secured, tested, and hosted like any other. Rebuilds are for deep data-model problems, and an audit tells you whether you have one.
How long does production hardening take?
One to three weeks for a typical app, alongside your continued feature work. The checklist items are parallel-friendly: monitoring and backups can be live in a day, while security review and test coverage take the bulk of the time.
Which builder platform is safest?
The differences matter less than the configuration. Every major platform can produce a secure app and an exposed one from the same feature set. Risk lives in database rules, secrets handling, and auth enforcement, which is to say in the last 30 percent, whoever generated the first 70.
Can I keep building with AI after hardening?
Yes, and you should. The guardrails exist for exactly that: tests on critical flows and a deploy pipeline mean the AI can keep shipping features while regressions get caught before users see them.
What is the single most urgent thing to check today?
Exposed secrets, then database rules. Search your client bundle and repo history for API keys, and test whether a logged-out request can read your data. Both checks take minutes, and both are the difference between a bad week and a breach.