Don't Rewrite the Vibe-Coded MVP: An Evidence-First Path to Production

A vibe-coded MVP needs an evidence-first path to production. The working product holds lessons that a clean build can wipe out along with the defects. A careful audit shows which components need replacing and which need proper infrastructure, so the business can lower risk and keep shipping.

What vibe-coded means in practice, and why the problem arrives on a delay

A prototype can work while omitting the layers that make it safe to operate. Authentication hardening, row-level security, secrets management, CI/CD, tests, observability, model-call cost caps and IP-clean licensing do not necessarily prevent an app from functioning at small scale. Their absence becomes consequential later. The production gap is therefore structural, even when the first users see a useful, working product.

Andrej Karpathy introduced the term vibe-coding in February 2025. By 2026, it is the dominant mode for non-technical founders reaching MVP, with AI-assisted development compressing a first testable version from months to weeks. The speed advantage reduces the cost of testing an idea, but the omitted layers become urgent when users reach the hundreds or low thousands, or when a regulator, procurement team or investor looks inside.

Why the instinct to rewrite is wrong in most cases

Rewriting is the wrong default for a product with users or revenue. Along with implementation mistakes, the existing code holds undocumented business rules and decisions shaped by how people actually use it. A multi-month rebuild puts that asset at risk immediately, while introducing a period of zero shipping and exposure to cost overruns. The argument rests on risk asymmetry. A plan for cleaner architecture alone cannot show that replacing the working system is safer for the business.

Phased modernization changes that exposure through the Strangler Fig approach. A facade sits in front of the existing system, and functionality moves across slice by slice, allowing value to ship in weeks. Budget exhaustion leaves a partly modernized working system. The strongest objection is that tangled generated code may cost more to modernize than to rebuild. That can be true, but an audit must establish it before the business commits to replacement.

What actually breaks first in a vibe-coded app, and how bad it gets

The security problems are specific enough to triage. Disabled row-level security is the most common and severe failure described in these apps, and it leaves names, emails and financial records exposed through client-bundled keys. The Lovable CVE-2025-48757 disclosure identified hundreds of vulnerable endpoints. This is a concrete access-control failure that deserves attention before a broad architectural cleanup.

Other defects include duplicated logic, dependencies that break easily, unclear architecture and missing edge-case tests. AI features have a separate cost problem when every request calls a frontier model without prompt caching, a cheaper sub-agent fallback or per-tenant token caps. Costs can grow without corresponding product value. A general verdict that the codebase is “messy” is insufficient because these failures require different remedies.

The “Rebuild Tax” makes early intervention economically important. Fixing a broken AI-generated MVP can cost far more than building a professional version from the start. Once a working product exists, the relevant choice is between repairing its identifiable weaknesses and replacing it.

What a disciplined audit actually examines, and what it produces

An audit examines architecture and scalability, code quality and test coverage, security posture, open-source dependencies and licenses, IP ownership, key-person risk and the proportion of AI-generated code. Security review includes RLS, secrets and authentication. The distinction must come from the codebase itself. Each area helps show whether a component needs to be replaced or can keep running on stronger infrastructure.

Four artifacts do most of the due-diligence work. They are a one-page architecture document, a test coverage figure, a software bill of materials and signed IP assignments from every contributor. Individual developers must sign because contractors retain rights in several jurisdictions unless they personally assign them. Coverage needs a practical production baseline. In a rescue, the goal is enough protection to catch regressions during infrastructure moves.

Five findings most often change deals, namely account ownership, UI-only authorization, untested backups, unassigned IP and dependence on a single key person. CTO on Demand sets clear limits with its fixed-fee 4-week engineering audit, agreeing on what work it will do and what it will cost before work begins. Vendor selection should apply the same discipline. A rescue provider should be able to show an audit template, an RLS threat-model document, a secrets-rotation runbook and a fixed-price phased proposal rather than sell open-ended time to get acquainted with the system.

The week-one infrastructure moves that are independent of any rewrite decision

Work to keep the system running can start before the final decision on architecture. A beta built on a prototyping platform can move from its prototype host to managed Postgres, removing a single point of failure while keeping the same application logic. Error tracking and uptime monitoring show when the system breaks so users do not have to be the ones to find out. These moves buy time for a sound decision. They also improve the operating conditions in which the audit takes place.

Secrets belong in a secrets manager while the rest of the security review goes on. That work deals with secrets exposure, but RLS and authentication still need to be checked on their own. For AI features, prompt caching, a cheaper sub-agent fallback and per-tenant token caps can control costs through configuration changes without a rebuild. The first week is therefore not passive observation. It is a period of targeted hardening that preserves the choice between lifting and replacing.

What technical due diligence checks in 2026, and how to pass it without a rewrite

Technical due diligence in 2026 examines the same seven areas as the audit, including how much code was written by AI. A vibe-coded system can pass without being rewritten if its specific findings have been addressed before diligence begins. Black Duck’s 2026 audit data found high-risk vulnerabilities in a large majority of audited codebases. Verizon’s 2026 data shows that nearly a third of breaches start with vulnerability exploitation.

Preparation should therefore focus on closing findings and documenting the result. A cleaner account of the technology cannot fix UI-only authorization, untested backups or unclear ownership. IP assignment is particularly unforgiving. If founders or contractors have not assigned all code to the company, investors may walk away, and an assignment from a contracting company does not replace the individual developer’s signature.

The four audit artifacts give that preparation a usable form. They make architecture, coverage, dependencies and ownership available for examination. The commercial consequences extend beyond engineering quality. A clean diligence process is a recoverable position for a prototype-derived business, while a failed process can reprice or kill a round.

When a fractional CTO is the right person to own this process

Businesses at an early stage often need CTO-level judgment before they have enough work to justify a full-time CTO. At that stage, choices about stack, architecture, build priorities and whether to rewrite have consequences. Fractional leadership fits that gap only with accountability. The person in this role must take charge of architecture, engineers, infrastructure and shipping, and report progress in plain business terms as well as give advice.

A technical co-founder can be the best outcome when the right person is available, but requires substantial equity and is difficult to find. A full-time CTO becomes justified when the team and ARR require daily presence. Between those points, a fractional CTO can provide delivery ownership without making a permanent appointment prematurely. The model’s suitability depends on whether someone is responsible for reaching the next milestone.

A planned transition can begin with leadership and process development in months 1–6, followed by defining and running the full-time hiring process in months 4–8. The full-time CTO starts in months 8–10 with a 60-day overlap, and the fractional leader moves to advisory work or exits from month 10. Candidate selection needs equal care. Red flags include never having held a full-time CTO role, emphasizing process over substance and lacking enough domain understanding to make informed build-versus-buy decisions. Slide decks without shipped software show that the engagement is set up the wrong way.

What the fractional CTO engagement actually costs, and how to read the structure behind a number

Fractional CTO pricing depends on what the person will take charge of, so prices are hard to compare without knowing what work they cover. Hourly work fits advisory assignments and one-off due diligence sprints, but works poorly for ongoing delivery leadership when billing for more time competes with solving a problem quickly. A fixed-scope project works well for an audit, migration plan or security review when both sides can agree in advance on what counts as done. Vague outcomes invite scope creep. The useful comparison is what gets delivered and who owns the result.

Monthly retainers are the most common model. CTO on Demand describes typical 2026 retainers as varying with weekly hours and scope of ownership, while experience depth and industry specialization distinguish the quality of engagements. No specific monetary range is established here. A precise price should therefore come from the proposed scope. The audit itself can be priced separately from the leadership required to carry out its findings.

Cash plus a small equity slice can align incentives for cash-constrained pre-seed founders. Equity above a low single-digit percentage for a non-cofounder, or an equity-only arrangement with no cash, is a red flag. Equity should be granted deliberately. The invoice also excludes the cost of a wrong architecture decision, whether that is rebuilding everything or continuing to extend a system that needs selective replacement.

Steve Johnson, a hands-on technology delivery lead for businesses scaling from prototype to production, has conducted dozens of technical audits for startups and established companies and finds that the replacement-versus-hardening distinction requires evidence from architecture, security posture, dependency health and the proportion of generated code. His engagement ladder provides one concrete audit-first option, moving from a free 30-minute consult to a fixed-price one-week Technical Audit & Roadmap, then a scoped pilot and an ongoing Fractional CTO retainer.

The decision the audit is designed to produce

The audit must produce a bounded decision. Its output identifies which components stay, which change and the order of work needed to keep shipping. The most common finding for a beta with live users is to lift and stabilize. When core logic is sound, managed infrastructure, observability and closed security gaps can support its operation as a production system.

A second outcome preserves most of the application while replacing a specific layer. Authentication, billing or a data model may be structurally broken even when the surrounding application logic remains reusable. The Strangler Fig approach supports that selective replacement. A third outcome is a clean build because the code is so entangled that modernization costs more, but that conclusion must be demonstrated.

The boundary between those outcomes is the audit’s central result. A one-week technical audit is the cheapest way to find out what not to build. Buy the audit before funding the rewrite.