Your developer is gone. The project doesn’t have to be.
The contractor stopped answering. The agency wound down. The one person who understood the system moved on. What is left is software your business depends on — half-finished, undocumented, or frozen mid-feature. Taking over someone else’s project is a discipline, and it’s one of ours.
Projects outlive the people who build them.
It happens more often than anyone advertises. A freelancer takes a better offer mid-build. A small agency closes or quietly deprioritizes its smaller clients. The technical co-founder burns out. An employee who built the internal system over five years retires, and the documentation turns out to live entirely in their head.
Most of these stories involve no villain — just a project that depended on one person, and then didn’t have them. The business is left holding something valuable and fragile at the same time: real software, real users, real revenue, and nobody who can safely change a line of it.
The wrong response is panic-hiring the first available developer, or accepting the first “this is unsalvageable, we should rebuild” you hear. The right response is an orderly takeover: recover what exists, secure it, understand it, then decide, with evidence, what happens next.
Stabilize first. Judge later.
The first days of a takeover are about control and safety, not opinions about the code:
- Access recovery. Repositories, hosting, domains, databases, app store accounts, third-party services — found, inventoried, and moved under your control.
- Credential rotation. Every key, password, and token the previous developer touched gets rotated. Not because anyone is accused of anything — because that’s simply what professional handoff means.
- A working build. We get the system building and deployable from your accounts, so change is possible again and the departure stops being an emergency.
- An honest map. What was built, what was promised, and what your business actually needs now — three lists, compared in writing.
Three steps from stalled to moving
-
Recover & stabilize
Access, credentials, backups, and a working build — the takeover items above, done in days, not months. Anything actively broken or exposed gets fixed in this step.
-
Production Blueprint
The same bounded assessment every engagement can start with: we inventory the code, infrastructure, and risks, then hand you a prioritized plan with a real estimate. The Blueprint is its own engagement — the plan is yours whoever builds it.
-
Resume delivery
The half-finished features get finished — or consciously cut — on a foundation that can carry them, with tests and deployment discipline so the next transition, whenever it comes, is a handoff instead of a crisis.
Ownership, on paper and in practice.
A takeover ends with your business holding what it should have held all along: your repository, your infrastructure under your accounts, rotated secrets, real documentation, and a runbook a future developer can pick up cold. We build so that we are replaceable — no hostage situations, including by us.
Custody is explicit from day one: an NDA by default before we look at anything, work done in accounts you own, every credential we touch rotated at handoff and never retained, and nothing about your code or your business reused anywhere else. The last arrangement gave one person too much leverage. This one is designed so that nobody has it — including us.
If what you have is an AI-built or low-code prototype rather than a departed developer’s codebase, the work is a close cousin — that path is described on Prototype-to-Production Rescue. And if you want to understand how a small senior team runs this kind of engagement, How We Work says it plainly, including who we are wrong for.
Asked by every owner in this situation
We do not have access to the code. Can you still help?
Often, yes. Code has a way of surviving: hosting accounts, deployment artifacts, database exports, app store builds, an old laptop, a repository the developer will hand over when asked professionally. We start by recovering what exists. If nothing can be recovered, we say so plainly and scope the honest alternative instead of pretending.
Will you just tell us to rewrite everything?
No. Rewrite-by-default is how takeovers get expensive. Whether to keep, harden, or replace each part is an evidence question, and the Production Blueprint answers it before you commit to anything larger. Working code that runs your business has value, even when it’s imperfect.
Do you need to talk to the previous developer?
It helps, and when a professional handoff is possible we will conduct it respectfully — most departures involve no villain. But it isn’t required. We routinely inventory systems with no one left to ask, which is exactly why the first step is a disciplined inventory rather than a guess.
The project is half-finished. Can you complete it?
That’s the most common shape we see. The inventory maps three lists: what was built, what was promised, and what your business actually needs now. They’re never the same list. You decide what "done" means with real information, then we deliver to it.
How fast can you start, and what does it cost?
If something is actively broken or exposed, stabilization comes first and starts quickly. The full path runs through the Production Blueprint: fixed scope, starting at $2,500, senior eyes, and a prioritized plan with a real estimate. You know the cost of the path before you walk it, and the plan is yours either way.
Tell us where the project stands.
Joseph reads every note and replies himself. If it isn’t a fit, he’ll say so and point you somewhere useful.
Start a Project