feliXart

Service

Software Takeover and Recovery

We take over a system somebody else left — after putting its condition in writing.

For half-finished projects, teams that have left and unowned codebases. Before promising to take anything over we run a paid review: the state of the code, whether it can be saved and what it risks, in writing. Sometimes the answer is "do not continue with this", and we say so plainly. The most expensive mistake here is spending months trying to rescue something that cannot be rescued.

What it covers04

Access and asset inventory

Domain, servers, database, code repository, store accounts and third-party services: in whose name they are registered and who holds access.

Code and architecture review

The state of the code, how current the dependencies are, security exposure, and which parts are worth keeping.

Data assessment

Where the data lives, whether it is backed up and whether it can be exported. It is the one thing in a project whose loss cannot be undone.

Recovery decision and roadmap

Continue, partially rewrite or rebuild — the cost and risk of all three, side by side.

Process04
01

Stop the loss

First we stop the bleeding: access is secured, code and data are backed up, and unpaid services are identified.

02

Assess

Code, architecture, data and infrastructure are reviewed and written up without the language of blame.

03

Decide

Continue, partial rewrite or rebuild, each with its cost and risk.

04

Take over

If you decide to proceed, we take the system on. If you do not, the report is yours and you can use it with another team.

FAQ05
My developer disappeared — what should I do first?
In order: change the passwords on the domain and server accounts, download a copy of the code and database to your own machine, and move the billing for paid services into your own name. These stop the losses that cannot be undone, and you can do them before calling anyone.
We do not have the source code — can you still look?
With access to the live system, partly. But a takeover is not possible without the code, so the first job becomes finding it or requesting it through legal channels.
Will you tell us if it cannot be saved?
We will. Sometimes the review concludes "do not continue with this", and we put that in writing. Trying to rescue something unsalvageable costs more than rebuilding it.
Will you speak to the previous developer?
If they can be reached, yes, and it usually helps. We are not looking for someone to blame but for how the system got here.
How long does the review take?
It follows the size of the system: days for a small codebase, weeks for a multi-unit one. We put the duration in writing once we have seen the access.

Has your system been left without an owner?

Let us establish its condition together. If it is not worth taking over, we will say so.