#Take over a vibe-coded project, or rebuild it?

More and more clients come to us with a project already built quickly with AI coding tools — vibe coding. The natural assumption is that continuing from the existing code will be cheaper. It usually isn't:

Taking over an existing vibe-coded project typically costs about 20% more than building it from scratch.

Clarifying the requirements, then redesigning and rebuilding, is usually both faster and cheaper.

#Why a takeover costs more

#We are accountable for the code we deliver

Every project we deliver comes with a 90-day free warranty and annual maintenance: after launch, bug fixes, security updates and incident response are on us. Taking over a project means taking responsibility for the quality of the existing code and the service built on it — not just the parts we write.

#Vibe-coded projects are built to ship fast

Vibe coding is designed to turn an idea into something that runs as quickly as possible, and it does that well. But speed comes at the expense of long-term operation. Common issues include:

• Structure piled up as it was generated: the same logic repeated in several places and unclear module boundaries, so one change ripples into others;
• No tests: there is no way to tell whether a change breaks existing behaviour;
• An ad-hoc data model: inconsistent field meanings, missing constraints and no migration history, making it hard to extend;
• Security gaps: secrets in the code, missing permission checks, unvalidated input;
• No deployment, monitoring or backups: running on a laptop is not the same as running reliably in production.

#Fixing the existing work takes extra time

Before we can build the features you actually want on such a codebase, we have to understand it, add tests, fix the risks and restructure it. That work never shows up on a feature list, but it is real and hard to estimate up front. It is where the extra 20% or so comes from.

#Our recommendation: treat the demo as requirements, not foundations

Your demo was not wasted effort. It validated the idea and pinned down the flows and screens, which makes it excellent requirements material. We recommend using it like this:

1. Capture the requirements — run our PRD prompt in the demo's codebase to have AI write a requirements document from the code.
2. Requirements assessment — send us the resulting prd.md to start our requirements assessment and produce a requirements draft.
3. Redesign and rebuild — from the confirmed requirements, we redesign the data model and architecture to production standards, then build, test and deploy.

Tell us about any existing data, users or interface designs in the demo during the assessment, and we'll work out how to migrate or reuse them.

#If you still need a takeover

Sometimes a takeover really is the better fit — for example, when the project already has real users and cannot go offline. We can still take it over:

• We start with a code assessment to establish the current state and the main risks;
• The quote (Model 1) or hour estimate (Model 2) is about 20% higher than building the same scope from scratch, to cover understanding, fixing and hardening the existing code;
• The actual uplift depends on the state of the code, and we confirm it after the assessment.

---

Tell us about your project and we'll help you decide whether to take it over or rebuild.