Application Rescue

Taking on software that is broken, unfinished, or has no one left who understands it, and making it maintainable again.

Inherited software is usually judged before it is understood. The code is unfamiliar, the documentation is missing, and a rewrite sounds cleaner than reading what is there. Sometimes a rewrite genuinely is the answer. It is worth knowing which case you are in before committing the budget.

Who it is for

Companies whose development partner stopped, left or was let go.
Founders holding a half-finished build with no clear route to completion.
Teams maintaining software nobody on staff originally wrote.
Anyone being told the only option is to start again from scratch.

Typical situations

The developer stopped responding

Work halts mid-project. What exists, whether it runs, and who holds the accounts are all unclear. The first task is establishing what you actually have, which is often more than it appears.

It works, but nobody can change it

The software runs in production and has done for years. There is no documentation, no test coverage, and nobody confident enough to modify it, so necessary changes keep getting postponed.

You have been told it needs a full rewrite

A rewrite is quoted as the only option. Sometimes that is right. Often it reflects unfamiliarity with the existing code rather than a genuine property of it, and the estimate deserves a second opinion.

Deployment depends on one person

Releases happen from a particular laptop, by a particular person, following steps that exist only in their memory. That arrangement works until it suddenly does not.

What we deliver

An assessment of what exists: source code, environments, accounts, data and what actually runs.
A written opinion on whether to continue, refactor or rewrite, with the reasoning.
A reproducible build and deployment process, documented and tested by someone else.
The critical defects fixed, in agreed priority order.
Tests around the parts that matter most, so future changes are safer.
Documentation sufficient for another developer to continue without us.

Typical timeline

A fixed-price assessment usually takes one to two weeks once read-only access is granted. Implementation duration is set out in the assessment report and depends on scope and change windows.

Starts with a fixed-price assessment

Read-only access first, so nothing changes while we look. You get a written finding, a recommendation and a price before any work is agreed. If the finding is that you should do nothing yet, that is what it will say.

Book a fixed-price assessment

Common questions

Can you tell us whether to rewrite or repair?

That is the main question the assessment answers. Rewrites are frequently proposed because reading unfamiliar code is harder than writing new code, not because the existing system is beyond repair. You get a reasoned recommendation either way.

We have lost contact with the original developer. Is that fatal?

Rarely. The usual obstacles are access rather than code: repositories, hosting accounts, domains and signing certificates. Recovering those is part of the work, and is checked first because it determines what is possible.

There is no documentation at all. Does that slow things down?

It is the normal starting point. Producing documentation is part of the output, not a prerequisite for beginning. The assessment is how the understanding gets built in the first place.

Will you end up rebuilding it in your preferred technology?

Not by default. Changing language or framework because it suits us would be your cost and our convenience. A change is only recommended where there is a concrete reason, and the reason is written down.

What if the honest answer is that it cannot be saved?

Then you are told that, with the reasoning and an estimate for the alternative. A clear negative answer early is cheaper than several months of work that leads to the same conclusion.

Nothing published on Application Rescue yet. Advisories and articles tagged for this service will appear here as they are written.