The message usually comes a week too late. The developer has stopped replying, the staging site is half-finished, and there is a demo on Friday. Most of the takeover work I do starts exactly here, and the first 48 hours decide whether the next month is a rescue or a rebuild.
[ADD: one or two sentences about a real takeover like this — what the client had when they came to you, e.g. "a repo, a Vercel login and no README". No client names.]
None of what follows needs a developer. It is the checklist I would want every founder to run before they hire anyone to fix anything, including me.
Find out what you actually own
Before anything technical, make a list of every account the product depends on and answer one question for each: is it in your name, or the developer's?
- The code repository (GitHub, GitLab, Bitbucket) — under your organisation, or their personal account?
- Hosting (Vercel, Netlify, AWS, a VPS)
- The domain registrar and DNS
- The database (Supabase, a managed Postgres, MongoDB Atlas) — do you have admin access, not just a login to the app?
- Payments, email, auth and analytics providers (Stripe, Resend, Clerk, and so on)
- App Store and Google Play accounts, if there is a mobile app
- The design files
Anything that lives in the developer's personal account is your top priority. Ask for a transfer in writing, politely, and keep it factual. GitHub and Vercel both support transferring a repository or project to another account, so the ask is small even if the relationship has gone quiet.
Lock things down without taking production offline
The developer still has keys to everything. Remove their access, but do it in an order that does not break the live app:
- Invite yourself as owner everywhere first, so you are never locked out.
- Rotate the secrets they had: API keys, database passwords, and service or admin keys. Update the new values in your hosting provider's environment variables and redeploy before you revoke the old ones, or the production app stops working mid-rotation.
- Then remove their accounts from the repository, hosting, database and third-party dashboards.
Take a database backup now, before anyone touches anything. It costs minutes, and it is the one thing you cannot recreate later.
Check that the code you have is the code that is running
This is the step people skip, and it is the one that bites. The repository and the production site are not always the same thing. Developers under pressure deploy from their own machine, keep unpushed work locally, or have a branch that never got merged.
Look at the hosting provider's deployment history. If the latest production deploy does not match a commit on the main branch, some of what is running live may exist only on the developer's laptop. That is worth asking about specifically, while they might still answer.
[ADD: if you have seen this — deployed code that was not in the repo — one sentence on what it looked like and what it cost to recover.]
Don't let the next developer start with a rewrite
When a new developer looks at an unfamiliar, half-finished codebase, the easy recommendation is to start again. It is almost always the wrong one. The existing code, however messy, holds hundreds of decisions and edge cases that nobody wrote down, and a rewrite rediscovers them one production incident at a time.
What usually fixes a stalled project is finding the small number of real structural problems under the large number of cosmetic ones. A dashboard that renders blank in production is rarely a frontend problem; more often it is one data assumption that holds on test data and fails on real data, and the fix is a guard in the right place.
[ADD: a short real example of a codebase that looked like it needed a rewrite and didn't — what the actual problem turned out to be.]
A rewrite is sometimes right: a framework version that no longer gets security patches, or a data model every feature has to work around. But that should be the conclusion of reading the code, not the opening pitch.
Pay for an audit before you pay for fixes
You cannot get an honest quote for "finish my app" from anyone who has not read the code. What you can get is a short, paid audit that produces a document you own. A useful one tells you:
- whether the code builds and deploys from the repository as it stands
- what is broken now, and what is fragile enough to break next
- any security problems — exposed keys, missing access controls, unvalidated input
- what it would realistically cost to get to a stable, shippable state
- what is fine and should be left alone
The last point matters more than it sounds. An audit that finds nothing good is usually selling you a rewrite.
This is how I run codebase takeovers: a written audit first, from $300, which you can act on with me or without me. If the app was built with an AI tool like Lovable, Bolt or Cursor, the same process applies — see AI-built app rescue.
What to tell users and investors
Say less than you think you need to, and say it early. "We are moving development to a new engineer and expect the next release in N weeks" is enough for most investors. For users, only communicate if something they rely on is actually broken. Do not promise a date until the audit is back; the audit is what turns a guess into a plan.
Questions founders ask at this point
How long does a takeover take? The audit usually takes a few days. The fix depends entirely on what it finds, which is why the audit comes first.
Should I hire the cheapest developer to finish it? Probably not. Finishing someone else's code is harder than starting fresh, and it is the part of the market where cheap work most often ends in a second rescue.
Can the original developer still help? Sometimes, and a short paid handover call is worth offering. Even thirty minutes on "what was the plan for X" can save days.
If you are in the middle of this right now, run the account list and the backup today — both are free and neither can wait. Then get the code read by someone before anyone quotes you a number. If you want that someone to be me, book a 15-minute call and bring whatever access you have; a repository and a hosting login are enough to start.