A good handoff starts with an intake audit before anyone touches the code, a written decision on what's kept versus replaced, and a mental-model transfer session — only then does a real team start committing, under branch protection and PR review from commit one.
Most founders who reach out have already built 60-80% of the product themselves in Lovable, Cursor, or bolt.new. That's not a problem we're solving for — it's the starting point we expect. The mistake studios make is treating that code like it's already broken. We treat it like any contributor's first pull request: reviewed, not blamed.
Will you just delete my code and start over?
No. We open the codebase, read it end to end, and score it against three questions: does it run, does it match the data the product actually needs, and can we explain a bug in it without re-reading the whole file. Most vibe-coded MVPs keep 60-80% of their CRUD screens and UI as-is — the same range we cover in vibe-coded MVP rescue or rewrite. Deleting working code to feel clean wastes money you already spent proving the idea works.
How long does the intake audit take?
One to two weeks, done before a single line changes. We map the codebase file by file: what's sound, what's fragile, what's a security risk. The output is a short written document, not a verbal opinion — a rescue-vs-keep call per module, so the founder sees the reasoning instead of taking our word for it. Skipping this step is how studios end up rewriting code that was fine, or shipping on top of an auth layer that wasn't.
What if my code is unreviewable?
It happens, most often with the auth layer or the data model — the two places a vibe-coding session is most likely to generate something that looks correct and isn't. If a module fails the audit, we say so in writing, with the specific reason, before any work starts. That's the boundary: we don't quietly rewrite a founder's code and bill for "improvements" they didn't approve. The decision on what's kept and what's replaced is made together, on paper, before commit one.
Do you charge for the audit?
Yes, and it's separate from the build. Bundling it into a build quote is how a founder ends up paying full price to discover, three weeks in, that half the codebase needs replacing. A standalone audit means the number they see for the rescue or rebuild is based on what we actually found, not a guess made before anyone opened the repo.
What happens after the audit — do we just start coding?
No. Before we touch anything kept, the founder walks us through it — a mental-model transfer session, not a document handoff. Why the schema is shaped the way it is, which shortcuts were intentional, which were the AI's guess. That hour saves a week of us reverse-engineering decisions nobody wrote down. Then branch protection goes on, every change ships as a PR with a real review, and the founder's own future commits go through the same gate as ours. The code doesn't get a pass because a person wrote it, and it doesn't get penalized because a model did.
Why does this process matter more than the code itself?
Because the handoff is the highest-risk moment in the relationship, not the code. A studio that skips the audit is pricing blind. A studio that skips the mental-model session is rebuilding institutional knowledge that already exists, slowly, at the founder's expense. Get the audit and the transfer right, and the actual engineering — kept code reviewed like anyone else's, fragile code replaced with reasons attached — is the easy part.
Written 2026-09-23 by Abhiraj Sakargaye.