Software takeover from another developer
We take over applications when the relationship with the previous developer ends. We review access, code and infrastructure, then agree repairs and ongoing maintenance.
What a software takeover covers
Access and billing
Code, hosting, DNS, databases, payments and app stores: who owns what, with transfers planned with the holders.
Production
What is deployed, what runs on a schedule and whether a backup actually restores.
First fixes
Expired certificates, unsupported dependencies and failing backups, before new features.
What changes
TodayNobody knows who holds which account.
With AL+A list of every account, its holder and its bill.
TodayNothing is written down.
With AL+The operating manual the system never had.
TodayEvery change feels risky.
With AL+One safe change through the full release path, and a restored backup.
How we take over the application
Fixed-price first review
What we examine and what you get, agreed in writing.
Inventory and access
Every dependency, its holder and its gaps.
Prove the path
A small change released, a backup restored, alerts that reach a person.
Then maintenance
A monthly responsibility, agreed separately.
Products built by AL+
We run KeySend and Milkglass ourselves, from releases and accounts to support. Our takeover checklist is public.
Who this is for
A good fit
Web apps, SaaS, APIs, mobile backends and internal tools with real users that need one accountable owner.
Look elsewhere if
You want developers by the hour, or help with a system you will shut down within months.
Questions
What if the previous developer won't give us access?
Access is the first job. We establish which accounts you already control and, with each holder and provider, whether transfer or recovery is possible. We cannot guarantee access you do not hold.
Will you want to rewrite it?
Not as a starting point. We recommend a rewrite only if the review shows repair would cost more, and explain why in writing.
Who owns the changes?
You do. Our changes sit in a repository your company owns, and the operating manual is yours.
Further reading
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.
Need someone to take over your software?
Tell us what the application does and what code and hosting access you hold. We establish what the initial review can cover.
Or copy the address: paul@alplustech.com