From Prototype to Production: What a Vibe-Coded Draft Still Needs

A prototype does not become production-ready just because it works. It becomes production-ready once it is clear what happens with invalid input, concurrent access, missing permissions, and error conditions, and once someone can operate it, change it, and roll it back in an emergency. That is twelve checkable points, not just a question of code quality.

Why does the jump from prototype to production fail so often?

Because a prototype answers a different question than a product does. The prototype answers: does this work at all? The product answers: does it hold up when a hundred people use it wrong at the same time, the network drops out, and in eighteen months someone else has to build in a change?

The prototype has no answer to any of these questions, not because it was built badly, but because they were never asked. The danger comes from how convincing the result looks: something that was demoed flawlessly in a meeting seems more finished than it actually is.

Which twelve points do I need to clarify before going live?

Data layer

• Catch up the data model. Prototypes often store everything flat and without relationships. What works in a demo later blocks every report and every change.
• Make migrations reversible. Every schema change needs a way back. A generated migration step with no counterpart is a one-way street.
• Check concurrency. What happens when two users change the same record at the same time? Never came up in the prototype, happens on day one in production.

Correctness

• Implement error cases. The OWASP Top 10:2025 lists mishandled exceptions as its own category for the first time (A10). Generated code reliably implements the normal case and swallows the rest.
• Validate input. Server-side, not just in the form. Prototypes validate in the browser because that is enough for a demo.
• Write tests for the behavior that needs to be protected. See test coverage for AI code.

Access

• Make permissions explicit. For every endpoint, one question answered: who may call this, and what happens if someone else tries? Broken access control remains unchanged at first place in the OWASP Top 10:2025.
• Get secrets out of the source code. Prototypes carry credentials in the code because it was faster.

Operations

• Inventory dependencies. Which packages are included, who maintains them, what license? Software supply chain failures have been their own OWASP category since 2025 (A03).
• Logging and alerting. If nobody notices it is broken, it stays broken longer.
• A rollback path. A deploy with no way back is a promise never to make a mistake.
• Clarify data protection. Which personal data is collected, on what legal basis, stored for how long, and who processes it on your behalf?

Is it worth rewriting the prototype?

More often than it feels like, but the decision should hang on one criterion, not on gut feeling. The criterion is: does someone on the team understand the structure well enough to change it with intent?

• Yes: then catching up is the cheaper path. Work through the twelve points above, in this order.
• No: then you pay for a rebuild either way, either deliberately now or spread out later over every single change. The prototype still has value as a specification: it shows exactly what the product is supposed to do.

The discussion around AI tools regularly underestimates this second case. GitClear's data shows that genuine code restructuring is falling sharply: the share of moved code dropped from 21 percent in 2022 to 3.8 percent in 2026. Where restructuring stops happening, a body of code grows instead that eventually nobody wants to touch.

How do I plan the transition realistically?

Treat the transition as its own project, not as leftover work. A prototype built in two days typically needs a multiple of that time for the twelve points, and that is not a failure, it is the normal distribution: the demo is the small part.

More reliable than any blanket estimate is a different approach: go through the twelve points, rate each one individually (done, open, unclear), and only estimate the open ones. That takes an hour and replaces a discussion that would otherwise run through the whole project. If you would like this path accompanied as a service, our SaaS development is exactly for that.

Frequently asked questions about going live

Can I put a prototype built with Lovable or Bolt straight into production?

Technically yes, responsibly only after the same twelve points. The origin of the code does not change the requirements: once real users and real data are involved, the requirements apply regardless of who or what wrote the code.

Is it enough if the tests are green?

No. Tests check what someone knew to check. In a prototype that is exactly the gap: error cases nobody thought of are also not tested.

What is the most commonly overlooked point?

Permissions. Business logic gets implemented reliably because it is part of the brief. The question "is this user allowed to do that?" is rarely part of the brief and is missing just as often.

Should I have someone review the prototype beforehand?

An external code audit before going live is significantly cheaper than one after an incident. What such an audit checks is covered in our code audit checklist.

The twelve points are quick to tick off and hard to actually work through. Code Guardian attaches the risky ones among them (migration, deploy, new dependency) to gates that stand before each step and require approval, instead of trusting that the list gets remembered at the right moment.

Sources

• OWASP Top 10:2025 (categories A01 Broken Access Control, A03 Software Supply Chain Failures, A10 Mishandling of Exceptional Conditions), final version January 2026.
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research.

As of July 27, 2026. General professional context; the specific scope depends on the individual case and does not replace an individual review.