Rescue & Recovery

First Get Your Property Back. Then Decide What to Build.

When a supplier stops answering, the immediate problem is not the code quality — it is that someone else holds the repository, the cloud account, the domain and the store listing. We start there, then audit what you have for a fixed fee and give you a written verdict either way.

Ownership

Nobody Discovers This Until They Need To

Every one of these is an ordinary situation for a UK company with an absent supplier. None of them is really a coding problem.

The repository sits in the agency's own GitHub organisation and your team has never had a login
The cloud bill arrives on the supplier's card and gets re-invoiced to you with a margin on top
Your app is listed under the developer's Apple account, so you cannot push an update or pull it down
The domain was registered by a freelancer in 2019 and the renewal email goes to an address nobody reads
Your customer database lives on a server you have no console access to and no backup you have ever tested
The contract runs to four pages, says nothing about intellectual property, and was signed by email in a hurry

Consider a letting agency that cannot change its own booking fees because the only person with production access has emigrated. The code is fine. The access is the crisis.

The Recovery

Each Asset Comes Back a Different Way

There is no single button. Every platform has its own route, its own evidence requirements and its own timescale, and knowing which lever to pull first saves weeks.

Routes to recovering software assets held by a previous supplier
What you are missing Where it usually sits The route back Roughly how long
Source code A private repository in the supplier's own organisation, or only on a laptop Ask for a transfer of the repository rather than a ZIP. Failing that, a full export including branches and issues. Failing that, we work from whatever is deployed. Days if they cooperate. Otherwise it is a contract question.
Cloud hosting An AWS, Azure, Google Cloud or DigitalOcean account in the supplier's name If the payment card is yours, the billing owner has a route in. If not, the realistic answer is a fresh account in your company name and a planned migration. A migration is usually one to three weeks of work.
Domain name A registrar account belonging to a freelancer or an old agency Request the authorisation code for a transfer. For a .uk domain, Nominet's registrant change process is the formal route where the registrant details are yours. Commonly five to ten days once the paperwork is right.
App Store listing The supplier's Apple Developer account Apple's app transfer moves the listing, its users and its reviews to your own account. It has to be started by the current holder and the app must meet the transfer conditions. Days when cooperative. Otherwise a new listing.
Google Play listing The supplier's Play Console account Play supports transferring an app between developer accounts, again initiated by the current owner. Keep the signing key in mind — without it you cannot ship an update to existing installs. Days, plus signing key recovery if needed.
Third-party services Stripe, GoCardless, Twilio, SendGrid, mapping and SMS accounts Payment accounts should already be in your company name for regulatory reasons. Everything else is usually a matter of resetting the owner email and adding your own billing. Same day for most, once you know the full list.

One practical note that costs people real money: if the previous supplier has been processing personal data on your behalf, you are still the controller in the eyes of the ICO. An account you cannot access is a security incident waiting to happen, and it should be dealt with urgently rather than filed under housekeeping.

The Paperwork

What Your Contract Probably Says About IP

Most of the contracts we are shown are short, friendly and silent on the subject. That silence is the problem. Under UK copyright law the person who writes the code is generally its first owner, unless they wrote it as your employee in the course of employment, or the contract assigned the rights to you in writing. A contractor is not an employee, and paying an invoice is not the same as taking an assignment.

The three arrangements we see most often

  • A written assignment on final payment. The cleanest outcome. Rights pass to your company once the last invoice is settled, and there is a clause naming what is included.
  • A licence rather than an assignment. You may use the software, sometimes only while you keep paying. Perfectly legitimate, frequently not what the client believed they were buying, and an unpleasant surprise during due diligence.
  • Nothing at all. No clause, no assignment, no licence terms. You may well have an implied licence to use what you paid for, but you are not in a position to assign it onwards to an acquirer or an investor.

Third-party components are a separate question

Every real codebase includes open-source libraries, and their licences travel with the code regardless of what your contract says. Permissive licences cause nobody any difficulty. Copyleft licences can create obligations that matter if you ever distribute the software. We list what is in there so you know, because the moment this becomes expensive is the moment an investor's technical adviser finds it before you did.

We are developers, not solicitors

Nothing on this page is legal advice. What we produce is a factual technical picture — what exists, who it appears to belong to, what is third-party and what an assignment would need to cover. Take that to a solicitor and the conversation costs a fraction of what it would cost them to work it out from scratch. See our NDA and IP page for how we handle ownership on our own work.

The Sequence

How a Takeover Actually Runs

Roughly four weeks from first call to writing production code, and most of the early part involves no coding whatsoever.

An asset register before a code review

We build a single list of every repository, cloud account, domain, store listing, payment provider and third-party service the product touches, with who holds each one and whether you can currently sign in. Clients are routinely surprised by the length of that list. Anything you cannot access becomes a recovery task with an owner and a date.

A code audit, quoted as a fixed sum first

You get the price before we start, so you are never buying an open-ended investigation. We read the code, run it, look at the database, check the dependencies for known vulnerabilities, review how personal data moves and test whether the thing can actually be built and deployed by somebody new. Typically one to two weeks depending on size.

A written verdict with a number against every option

Not a grade out of ten. A document that says continue, or rebuild this part, or rebuild the lot, with a sterling estimate excluding VAT beside each route and the reasoning stated plainly enough for a non-technical board to follow. Where we are uncertain we say so and explain what would resolve it.

Stabilisation before anything new

If the product is live, the first fortnight goes on the things that stop you sleeping: crashes, the payment path, security holes, expiring certificates, a backup that has never been restored. No new features until the existing ones stay upright. This part frequently changes a client's mood about the whole project.

Forward work, on a model you choose

Once it is stable you pick how to proceed — a fixed-price scope for a defined piece of work, a dedicated team by the month, or a maintenance retainer if the honest answer is that the product needs keeping alive rather than growing. We will say which one we think fits and why.

The Audit

Four Piles Everything Gets Sorted Into

A findings list of ninety items helps nobody. We sort every finding by what it will cost you if you leave it alone, which is the only ranking a board can act on.

Fix before anything else

Legal, Regulatory or Contractual Exposure

Personal data held where it should not be, or kept far longer than any stated retention period. No route to service a subject access or deletion request. Card details touching your own servers. Passwords stored in a form that would be reportable to the ICO if the database leaked. Accessibility failures against WCAG 2.2 AA where you sell to councils, the NHS or universities. Open-source licence obligations that conflict with how you distribute the product. These are not technical debt. They are liabilities with a clock on them.

Fix inside the first quarter

Will Break Under Growth or at Renewal

Database queries that are fine at a thousand records and hopeless at a million. A framework version that stops receiving security updates within the year. Certificates and API keys with no owner and no renewal reminder. Deployment that only works from one person's laptop. No error tracking, so you learn about failures from customers. Infrastructure sized for a demo and now carrying real traffic. Each of these has a date attached, even if nobody has written it down.

Real, but we would leave it

Debt You Can Live With

Inconsistent naming, duplicated code in places nobody edits, an unfashionable library that works perfectly well, patchy automated tests around stable areas, a build that takes six minutes. An audit written to sell a rebuild puts all of this on the front page. We put it in an appendix and tell you it is cheaper to tolerate than to tidy, unless you happen to be working in that area anyway.

Keep it

Work Worth Protecting

There is almost always something good in there, and it is usually the part that encodes how your business actually works — the pricing rules, the rota logic, the VAT handling, the awkward integration with a supplier's ageing system. That knowledge took years of arguments to accumulate and is the single most expensive thing to recreate from scratch. Our report names it explicitly so nobody later throws it away by accident.

The Verdict

Starting Again Is Rarely the Cheap Option It Appears to Be

Any developer looking at code they did not write will want to replace it. That instinct is genuine, it is occasionally right, and it is the most expensive advice in the industry.

What a rebuild really costs

  • Twelve to eighteen months during which your product gains nothing a customer can see.
  • Every rule the old system learned the hard way has to be rediscovered, usually by a customer complaining.
  • Two systems to run and pay for during the changeover, not one.
  • A migration of live data that is nobody's favourite fortnight and is always underestimated.
  • The new build accumulates its own debt from about month four, because all software does.

When we do say rebuild

  • The framework or platform is out of support and there is no upgrade path that does not amount to a rewrite anyway.
  • Adding a routine feature takes weeks because every change breaks something unrelated.
  • The data model genuinely cannot express what the business now does — single-branch assumptions in a multi-site retailer, say.
  • Security problems run right through the design rather than sitting in a few places.
  • The product is small enough that rebuilding costs less than a year of working around it.

Where a rebuild is right we rarely do it all at once. One boundary at a time, old and new running side by side, each slice paid for by the feature work happening around it — so you are never twelve months from a release.

No Strings

What We Will Tell You Even If You Do Not Hire Us

The audit is a paid piece of work and the output belongs to you. There is no version of it that we hold back, and there is nothing in it written to make the next proposal easier to sell. If you take the report to another firm and they do the build, that is a perfectly acceptable outcome and it has happened.

  • If the code is better than you were told, we say so — even though that means a smaller job for us
  • If the honest answer is that the product should be retired rather than rescued, you get that in writing
  • If the previous developer's work was competent and the real problem was scope or budget, we will say that too
  • You get the asset register and the recovery steps regardless of who does the work afterwards
How we run a build afterwards

What the report contains

  • An asset register with an owner and a recovery route against every line
  • Findings sorted into the four piles above, each with an estimate of effort
  • A dependency and open-source licence inventory
  • A note on where personal data sits and how a deletion request would be serviced
  • Continue, part-rebuild or full-rebuild routes with a sterling range against each, excluding VAT
  • A first ninety days, written as a list of things rather than a strategy
Ask What an Audit Would Cost
Honesty

When We Are the Wrong People to Ring

Rescue work attracts urgency, and urgency makes people hire whoever answers the phone. A few situations where that should not be us.

You need somebody in the building today

If a live incident needs hands on it within the hour, at any hour, we are not that supplier. We overlap your morning and we reply within one business day — which is not the same as an on-call rotation. Say so early and we will tell you straight.

You want a second opinion to win an argument

If the decision is already made and what is wanted is a document supporting it, we will decline. The audit says what we actually found, which sometimes contradicts whoever commissioned it.

The product has no users and no budget

Where an abandoned build has never had a customer, rescuing it is often sentimental rather than commercial. Starting deliberately small usually beats resuscitating something that never worked. See MVP development.

FAQ

Takeover and Recovery Questions

The agency that built our app has been dissolved at Companies House. What can we actually recover?

More than you would expect, because most of the assets do not sit inside the company itself — they sit with platform providers who have their own recovery routes. A domain can usually be recovered through the registrar with evidence of who the registrant was meant to be. A cloud account billed to your card can often be recovered by the billing owner. Apple and Google both have processes for a listing whose developer account has been abandoned. The genuinely hard case is source code that only ever existed on a private repository nobody can now sign into, which is why our first job is to establish precisely what is missing rather than assuming the worst. Where property has passed to the Crown as bona vacantia you need a solicitor, not a developer.

Our contract with the previous developer never mentioned intellectual property. Where does that leave us?

In an awkward position rather than a hopeless one, and this is a point where we will tell you plainly to speak to a solicitor. Under UK law the first owner of copyright in code is generally the person who wrote it, unless they wrote it as your employee or the contract assigned the rights to you in writing. Paying an invoice does not by itself transfer copyright, although a court may find you hold an implied licence to use what you paid for. What we can do is tell you which parts of the codebase are third-party open source, which parts were written specifically for you, and what an assignment would need to cover if you go and ask for one. What we will not do is give you a legal opinion.

Our app is live on the store under an account belonging to the previous developer. Can it be moved?

Usually, yes. Apple supports transferring an app between developer accounts and Google Play supports a transfer too, but both attach conditions and both require the current account holder to start the process. If they cooperate it takes days rather than weeks and your existing users, ratings and reviews travel with the listing. If they refuse, the fallback is republishing under your own account as a new listing and migrating users across, which costs you the review history and a share of your installed base. That difference is usually worth being extremely polite for a fortnight before escalating.

All we have is a ZIP file of the code with no version history. Is that enough to work from?

It is enough to audit and usually enough to continue from. What you lose without the version history is the ability to see why something was written the way it was, who changed it and whether an odd-looking workaround was a deliberate fix for a live incident. That makes the audit slower and makes our first few weeks of changes deliberately cautious. We put the ZIP into a fresh repository inside your own organisation on day one, so at least the history starts accumulating from the moment you took control.

We are in a dispute with the previous supplier. Will you still take the work on?

Yes, on one condition: we stay out of the dispute. We will write a factual technical assessment of what exists and you may use that document however you wish, including in a dispute. We will not write an opinion shaped to support a claim, act as an expert witness, or contact the other side on your behalf. In our experience a plain description of the state of the code reads as more credible than an adversarial one in any case.

Do you need to speak to the previous developer at all?

It helps enormously and it is rarely available. An hour of handover from the person who built the thing saves several days of reading, so we always ask whether that conversation is possible and we keep it civil and technical if it happens. Where the relationship has broken down entirely we work from the code, the running system, the database and your own account of how the business actually operates. That is slower, and it is the normal case rather than the exception.

Send Us the List of Things You Cannot Log Into

Even before there is a project, we will tell you which of them can be recovered and roughly how. You get a scope and a sterling range for the audit within two working days.