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.
Run a fictional company's inventory: what it owns, what others hold, what is missing.
- Code repository Not checked Yours
- Hosting Not checked Old developer Moved to you
- Domain and DNS Not checked Yours
- Database Not checked Old developer Moved to you
- Backups Not checked Missing Restored and tested
- Email sending Not checked Old developer Moved to you
- Payment account Not checked Yours
- App Store account Not checked Yours
- Error alerts Not checked Missing Set up, alerts reach Paul
Operating manual
- How to deploy
- How to roll back
- How to restore the database
- Whom to call at each provider
- What does the software depend on? Nine things nobody has listed in one place.
- Who holds each one? Some are yours, some sit on the old developer's accounts, one is missing.
- Bring them under your name Transfers agreed with the holders; access you control.
- Prove the backup A backup restored on a test environment, for the first time.
- The operating manual Deploy, roll back, restore, whom to call. Written down.
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.
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.
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