Software takeover after your developer or agency leaves
Your application still has users, but its original developer has moved on. We assess the code and access you can authorise, then propose how to take responsibility for it. You get a documented plan before committing to takeover work or ongoing maintenance.
When you need a takeover
The software works well enough to keep, and the people who understood it have gone. It usually happens in one of four ways.
-
The developer left
A freelancer or an early employee built the product and moved on. The code is often fine. The knowledge of how it is deployed, where the secrets live, and why it was built this way left with them.
-
The agency relationship ended
The agency that built the system is too expensive, too slow, unresponsive, or closed. You may not have full access to the repositories, the hosting, or the domain. Getting that access is the first job.
-
The internal team no longer understands parts of it
The system grew over years. Some modules have no owner. Changes near them are avoided, and every estimate that touches them is wide and nervous.
-
Nobody can explain how it works
A founder or a small team got a working application to customers quickly. Nobody on the team can describe how it fits together, which is a different problem from it being badly written. If it also breaks or exposes data, start with application repair.
Signs your software has lost its owner
Unowned software slows down long before it breaks. Watch for these:
- Small changes take weeks, and nobody can say why.
- Outages end with someone restarting a server, and nobody learns why it happened.
- Dependency and security updates are postponed because nobody knows what they might break.
- Accounts, domains, certificates, or API keys are registered to people who no longer work with you.
- Backups are assumed rather than tested.
- Every conversation about the software starts with "we would have to look into that".
The expensive outcome is a full rewrite ordered only because nobody understands the current system. Understanding it first usually costs far less. Read how we decide between repair and rewrite.
How we take over a system
Access first, then production, then the knowledge nobody wrote down. We follow the same order on every takeover and start new features only after it is done.
It begins with a review at a fixed price, agreed in writing. The review tells you what we found, what can't wait, and what the next steps would cost, before you commit to anything more. You pay weekly in advance, and either side can stop with one week's notice.
-
1. Secure access and billing
Source control, hosting, DNS and registrar, databases, email delivery, payment providers, third-party APIs, app store accounts, monitoring. We record who owns each account, confirm the access you can authorise, and plan any transfer or credential changes with the account holders. Provider restrictions and billing dependencies are included in the report.
-
2. Review production, not only the repository
What is actually deployed and from which commit. What runs on a schedule. Which external services the system talks to. What data exists, how large it is, and whether a backup can be restored. What the logs say has been failing quietly.
-
3. Recover the knowledge nobody wrote down
If the previous developer is reachable, a few paid hours of questions are worth weeks of archaeology. Then we write the operating manual the system never had: how to deploy, roll back, restore, and whom to call at each provider.
-
4. Ship one safe change end to end
A trivial change through the full path: commit, review, test, deploy, verify, and a known way to undo it. Whatever is missing or manual on that path gets fixed first.
-
5. Fix the fragile parts, then the wanted ones
Expired certificates, unsupported dependencies, failing backups, single points of failure. Feature work starts after that, with estimates based on what we now know about the system.
The full list of what we look at is public: the codebase takeover checklist. Use it with any team, including your own.
What you have when the takeover is done
The takeover scope defines the improvements we will demonstrate, such as a repeatable release, a restored backup or monitoring with an agreed contact. The handover records account ownership, access restrictions and remaining work, so another engineer can understand the system.
Hosting and third-party services stay billed to your accounts by their providers, separately from our work. Our list of what a handover should contain is the standard we hold our own documents to.
From there the work becomes software maintenance: a monthly responsibility for keeping the system correct, changeable, and improving. Where the system also needs structural change, that happens as modernization in place, one bounded step at a time.
Who this is for
-
A good fit
Web applications, SaaS products, APIs, internal tools and their infrastructure, with real users and real data. Companies that want one accountable technical owner they can call.
-
Look elsewhere if
You want developers by the hour, a one-off emergency rescue with nobody responsible afterwards, or help with a system you will shut down within months. Mainframes and large desktop estates are outside our experience, and we will say so in the first reply.
Questions about taking over software
What if the previous developer won't give us access?
Getting access is the first job of every takeover. We list every account the system depends on and work out which ones your company already controls. For the rest, we establish whether transfer or recovery is possible with the account holder and provider. We cannot guarantee access or ownership that you do not hold.
Do we need the previous developer to be available?
No, though it helps. A few paid hours of their time answering questions can save weeks of reading code. If they are not reachable, we learn the system from production, the code and the logs.
Will you want to rewrite it?
Not as a starting point. Most systems that reach us are worth keeping. We recommend a rewrite only if the review shows that repairing the system would cost more, and we explain the reasons in writing.
How is a takeover priced?
The first review has one fixed price, agreed in writing before we start. It tells you what we found and what the next steps would cost. After that, takeover work is scoped and priced in writing, and ongoing maintenance is a separate monthly agreement.
What do we have at the end of the takeover?
The agreed work and an operating manual, including account ownership, deployment, recovery and monitoring arrangements. Any unresolved access or provider restrictions are recorded. The assessment establishes which of these improvements are feasible before the takeover scope is agreed.
Can you take over software built by a large agency?
Yes, if it is a web application, SaaS product, API or internal tool on a common web stack. We look at the system before agreeing to anything, and we tell you in the first reply if it is outside our experience.
Related thoughts
-
Codebase takeover checklist: what to inspect before accepting a system
A reusable checklist for taking over software from another developer, agency, or team: access, production, data, change safety, dependencies, security, knowledge, and cost. Use it before you agree to own the system.
-
What a good software handover should contain
The seven artifacts an outgoing developer or agency should hand over with a software system: access, environment map, operating manual, architecture notes, decision log, open issues, and a recorded walkthrough.
-
Taking over software after the developer leaves
A practical sequence for inheriting a system whose builder is gone: secure access, understand production, write down what nobody wrote, then change things.
Is your software running without an owner?
Write a few sentences: what the system does, who built it, whether you can still reach them, what you have access to, and what worries you. If you don't know what it runs on, that's fine. Please keep passwords out of the email.