Nobody wrote this code. Now a human has to own it.

A normal codebase handoff has a shortcut built in: the incoming developer asks the outgoing one why things are the way they are. That shortcut does not exist here. Nobody wrote the code. The founder steered it into existence prompt by prompt, and when the new developer asks "why does auth work this way?" the honest answer is "I don't know, it came out like that and it worked." Every why has to be reconstructed from the code itself, which is the slowest kind of reading there is.

And many developers simply will not do it. Spend ten minutes in the developer subreddits and the sentiment is unmissable: one r/webdev thread declares the handoff between no-code builders and developers completely broken, arguing the gap is the same whether the builder used a no-code tool or an AI agent, and an r/ExperiencedDevs thread from a rescue specialist is titled, verbatim, "Saving challenging projects was my niche, but AI codebases are making me miserable." The refusals are not snobbery, or not only snobbery. Reading intent out of generated code is real work that most developers never priced, never practiced, and did not get into the field to do.

So the market splits. Founders with working apps search for someone to take over. Most developers decline, quote a rebuild to make the problem go away, or accept and burn out on it. The small group who handle these well treat the takeover as a discipline with a sequence, which is exactly what the rest of this page describes.

Alongside the access list, write three short documents. First, environment and deploy notes: how a change gets from the AI tool to production, which environment variables exist and where they live. Second, the known-broken list: every bug, workaround, and "do not touch that button" you are aware of, in plain language, without embarrassment. An honest known-broken list is the single most trust-building artifact a founder can hand over. Third, data sensitivity notes: what personal, payment, or health data the app holds, so the successor knows what they are now responsible for protecting.

If you are still choosing a platform or wondering what your platform already exposes, the platform guides cover that side: is Lovable safe, is Bolt safe, and the rest of that series. And if the app is changing hands because the person who understood it is gone, the developer-left guide covers the messier version of this same package, assembled without their help.

Mapped to our ladder, plainly: Ship Check is the assessment mechanism, $299 fixed, and it produces the written read whether or not you continue with us. Ship Fix is the stabilization pass, $4K to $15K by scope. Continuum is the relationship: Care at $500 to $1,500 per month keeps the exposure handled as the app changes, and Partner at $3,000 to $15,000 per month puts a senior engineer in every critical loop, which is the takeover in its fullest form. The fractional CTO pricing guide shows how that band compares to the wider market, and the SaaS maintenance cost guide covers what ongoing ownership of an app like yours should cost in general.

If you want a zero-commitment first step before any of that, the free Leak Check reads your live URL in about a minute and tells you whether anything is exposed right now, which is worth knowing before you give anyone access to anything.

The same sequence protects you from the other side. Never quote maintenance on a codebase you have not read; charge for the assessment, timebox it, and put the findings in writing, because the written read is what turns an unbounded liability into a scoped job. Assume the founder's account of the app is sincere and incomplete: they know what it does, not how, and the support inbox knows things they do not.

Refuse the hostage position too, in reverse. Holding a client's repo or domain on your accounts feels like leverage and is actually risk: it makes every departure a fight and every fight your fault. Work inside their accounts, document what you change, and let retention come from being worth keeping. The founders reading this page are being told to demand exactly that, so the developers who already work this way are the ones who will get hired.

On retention, hold us to the same standard. Our longest client relationship is 15+ years embedded as the technical partner for the same business, documented with the rest of the track record on the proof page. That number is the axis we think successors should be judged on: not how long a firm has existed, but how long clients keep choosing the same operator when leaving is easy. Ask every candidate the same question and listen for a specific answer.

Three patterns predict a bad takeover reliably enough to treat them as disqualifying. A rebuild-first pitch delivered before any assessment: nobody can know your app needs a rewrite without reading it, so a pre-read rebuild quote is a sales position, not an engineering judgment. A retainer with no defined proof of work: if you cannot say what you received last month, you did not buy maintenance, you bought reassurance. And access held on the vendor's accounts: the moment your repo, domain, or database lives under their login, the price of leaving is your product.

And because no single successor fits everyone: if your app needs deep product rework rather than stabilization and stewardship, a full rescue-and-rebuild engagement may fit better than our ladder. Justin McKelvey runs a Vibe Code Rescue at $25K to $50K over 4 to 8 weeks, starting with a free repo audit, with ongoing fractional CTO work reserved for clients after a first engagement, per his published pricing as of July 2026. General dev shops make sense when the verdict really is a ground-up rebuild and you need a team, not an operator. If your app was recently breached rather than merely fragile, start with the hacked-app guide first, because incident response comes before any handoff.

The honest summary: the handoff market is thin, the refusals are real, and the fix is process, not luck. Assemble the package, buy the assessment, keep your keys, and judge every candidate, including us, on retention and exit terms.