Software Rescue: Take Over and Fix an Existing Project

Description

Service Software rescue: take over and fix an existing project

Software rescue means taking over code that someone else wrote and getting it to a state you can rely on. WavX starts with a short audit of the code, the hosting and the access you hold, tells you plainly whether it is worth repairing or cheaper to rebuild, and only then quotes for the work.

Get a technical assessment Last updated 2 October 2026

When a project needs rescuing

Most rescues start in one of four ways:

The developer or agency has gone. A freelancer stopped replying, an agency closed the account, or the one person who understood the system left the company.

The project never finished. Months of payments, a demo that mostly works, and no launch date.

It launched and it is unreliable. Orders go missing, pages time out, the app crashes on some phones, and every fix breaks something else.

It works, and nobody can change it. No documentation, no tests, and each new feature is quoted at several times what it should cost.

The fourth is the most expensive over time and the least visible. If changes to your software have become slow and risky, that is the same problem as the first three at an earlier stage.

What WavX needs from you

A takeover goes quickly when these are in your hands, and slowly when they are not. If your developer has just left, secure these first before anything else.

Item

Why it matters

If you do not have it

Source code repository, with history

The code itself, and the record of what changed and when

We help you request it, or recover what we can from the server

Hosting and cloud accounts

Where the software runs; who pays the bill

Ownership is transferred to an account in your company's name

Domain and DNS

Controls where your users are sent

Recovered through the registrar using proof of ownership

Database access and backups

Your data

A fresh backup is the first thing we take

App Store and Play Store accounts

Needed to publish any update

Apps must be transferred or republished under your own account

Third-party keys: payment gateway, SMS, email, maps

The integrations stop if these lapse

Reissued from each provider under your account

Any documentation, designs, or task lists

Saves audit time

We reconstruct what we need from the code

All of these should belong to your company, not to a developer. Part of every rescue is moving them there.

How the takeover runs

1. Audit

We read the code and run it. The audit answers a fixed set of questions:

Does it build and run from the repository, on a clean machine?

What is it built with, and are those versions still supported?

Where is data stored, and is it backed up?

Are passwords, keys and personal data handled safely?

Are there tests? Do they pass?

What breaks most often, according to the logs?

Which parts are sound, which are fragile, and which are unsafe?

You get the answers in writing, in plain language, with a recommendation.

2. Repair or rebuild

The recommendation is one of three:

Recommendation

When it applies

Repair

The structure is sound; the faults are local. Fix them, add tests, document.

Repair now, replace in stages

The system must keep running, but parts of it will not survive growth. Stabilise first, then replace one part at a time.

Rebuild

The code cannot be made safe or maintainable for less than building again. We say this only when the numbers show it.

A rebuild is not always the expensive answer, and repair is not always the cheap one. A system that needs a week of developer time for every small change costs more each year than its replacement would. For a planning range on a rebuild, use the software cost estimator ; the rescue itself is quoted after the audit.

3. Stabilise

Before any new feature: backups that are tested, errors that are logged where someone will see them, the known crashes fixed, and access cleaned up so that former developers no longer hold keys.

4. Continue

Once the system is stable it becomes ordinary work: new features, maintenance, and the changes the business had been waiting for.

What the audit usually finds

No two inherited systems are the same, but the same faults turn up often enough to check for by name.

Area

Common fault

Access

Passwords and API keys written into the code

Anyone with the code has the keys, including people who have left

Data

No tested backup; backups on the same server as the data

One failure loses both

Deployment

Changes are copied to the live server by hand

No record of what changed, and no way back

Dependencies

Frameworks and libraries several major versions behind

Known security holes; upgrades get harder the longer they wait

Structure

One very large file or module doing everything

Every change risks breaking something unrelated

Tests

None, or tests that no longer run

Nobody can tell whether a fix broke something else

Errors

Failures are swallowed and never logged

Problems are reported by customers, days later

Payments and messages

Incoming webhooks are not verified or are processed twice

Orders marked paid that were not, or charged twice

Each finding in the report is marked as urgent, important or cosmetic, so you can decide what to fix first and what to leave.

What you receive at the end

The system running from a repository your company owns, with a written description of how to build and deploy it.

Every account (hosting, domain, database, app stores, third-party services) in your company's name.

Tested backups and error logging.

Automated tests around the parts the business depends on: taking payment, placing an order, logging in.

A short list of what was left alone and why.

The last item matters. A rescue that tries to fix everything never finishes; one that documents what it did not fix lets the next person carry on.

What a rescue cannot do

It is better to hear these at the start.

It cannot recover code that no longer exists. If there is no repository and no server copy, the software has to be rebuilt from what it does, not from what it was.

It cannot make a wrong product right. If the software was built to the wrong requirement, repairing it produces a reliable version of the wrong thing.

It cannot be estimated accurately before the audit. Anyone who quotes a fixed price to fix code they have not read is guessing.

When you should not hire anyone for this

If the software is a small website or a simple store, and it runs on a standard platform, moving to a maintained platform is often cheaper than rescuing custom code. We will say so if that is what the audit shows. Rescue is worth it when the software holds your data, your process or your customers, and replacing it would cost the business more than fixing it.

If the code came from an AI coding tool and worked in a demo but not with real users, read rescue for apps built with AI coding tools. The faults are different enough to need their own checklist.

Rescue work is one part of custom software and business systems at WavX.

Frequently asked questions

Can you work with code that another developer or agency wrote?

Yes, provided we can get the source code and access to where it runs. The first step is an audit, because the honest answer to whether the code is worth keeping depends on what is actually in it. We tell you the result of that audit before quoting for any repair work.

What if I do not have the source code?

Then the first job is recovering it, from the previous developer, from the hosting account, or from the app-store build. If the source cannot be recovered, the software has to be rebuilt, and we will say so at the start instead of after billing for an attempt.

Will you rewrite everything?

Only if the audit shows a rewrite is cheaper than repair over the next two years. Most rescues are a mix: keep what works, replace what is unsafe or unmaintainable, and add tests around the parts the business depends on.

How much does a rescue cost?

It is quoted after the audit, because the cost depends on what the audit finds. We do not publish a figure for rescue work. For a sense of what a rebuild of the same system would cost, the software cost estimator gives a planning range.

Our app was built with an AI coding tool and now breaks in production. Can you fix that?

Yes. That is a rescue with its own typical faults, mostly around security, data handling and missing error paths. There is a separate page on it.

Related

Your developer left: what to secure first

Custom software and business systems

Software cost estimator

Build your own software — your way, your pricing.

WavX Solutions is here to create your own software in a fully custom way, built exactly how you work — with a pricing model that fits your business. Connect now and let's build it.

Contact Now helpwavx@gmail.com