Services / Care / Software we didn't build

Your developer vanished. We'll take it from here

An orphaned system is usually fine right up until the day it is not: nobody knows how to deploy it, the domain renewal goes to an email address that no longer exists, and the one person who understood it is unreachable. We take these on: health check first, dangerous things stabilised, documentation written as we go.

Start the conversation →See the technology

Why it matters

The cost is the wait

This happens to competent organisations constantly. The freelancer who built it moves abroad. The agency is acquired and the team disperses. The in-house developer who knew everything leaves on good terms and takes the knowledge with them, because nobody ever asked them to write it down. It is not negligence; it is the normal life cycle of software that was working fine and therefore never demanded attention.

The symptoms are recognisable. No documentation beyond a handful of emails. Credentials in a spreadsheet, or in nobody's possession at all. Deployment that only ever happened from one person's laptop. A backup arrangement nobody has tested, or in several cases nobody can locate. And an understandable reluctance to touch anything, which means small problems go unfixed until they become large ones.

We start with an honest health check, and "honest" is doing real work in that sentence. Most inherited systems are considerably more salvageable than they look, and a supplier whose first instinct is always to rebuild is telling you about their commercial preferences rather than your software. Occasionally the right answer genuinely is to replace it, and we will show you the reasoning. Either way the sequence is the same: recover ownership, stabilise what is dangerous, prove you can restore it, get it off one laptop, then write it all down.

What you actually get

Built to be trusted

Adoption is a defined piece of work with a defined finish line, not an open-ended archaeology bill.

An honest health check first

A written assessment of the code, dependencies, hosting, security posture, data and backups, with a rating and a recommendation. "Rebuild" is one of the possible answers, and so is "this is in better shape than you feared", which is more often the case than not.

Ownership recovered and put in your name

Domains, DNS, hosting, cloud accounts, repositories, third-party services and every credential, transferred into accounts your organisation controls with us added as collaborators. This is usually the single most valuable outcome of the whole exercise.

The dangerous things stabilised first

Exposed admin panels, unpatched vulnerabilities with public exploits, expired or expiring certificates, absent backups, credentials sitting in the code. These are dealt with before anything else, in an agreed order, and before a single feature is discussed.

A deployment that is not one person's laptop

Code into version control you own, a reproducible build, a staging copy and a scripted deployment with a rollback. Until this exists, every change is a risk and nobody can safely help you, which is exactly how these situations arise.

Documentation written as we go

Architecture diagrams, a runbook, an account register and recovery procedures, produced while we are learning the system rather than promised for later. The test we hold ourselves to: another competent team could take over from the documents alone.

Unfashionable stacks welcome

Older PHP, elderly WordPress builds.NET, Node from several major versions back, a database schema with opinions. We do not require a rewrite as the price of support. If it works and it can be made safe, it deserves to keep earning its keep.

Where it earns its keep

Same pattern, different desks

Different organisations, the same story: something important is running, and nobody currently employed knows how it works.

01 · Manufacturing & distribution

The system the whole factory runs on

The problem: A bespoke stock and ordering application, written by a contractor over a decade ago, sits between purchasing, the shop floor and despatch. It works. Nobody dares touch it, the server it runs on is well past its supported life, and the contractor's phone number has not connected for years.
What we build: A full inventory of what the application actually does, captured from the code and from watching people use it; the server rebuilt on a supported platform with the application containerised so it can be moved again; backups proven by an actual restore; and the business logic documented in language the operations manager can verify.
What changes: The same trusted system, now on maintained infrastructure with a tested recovery path, and a written description of the rules the business has been relying on without ever having them recorded.

02 · Charities & membership organisations

The donations site a volunteer built

The problem: Donations, membership renewals and the mailing list all run through a site built years ago by a supporter who has since moved on. It holds personal data, the payment integration is on an old API version the provider keeps emailing about, and nobody knows who controls the domain.
What we build: Ownership traced and recovered first, including the domain and the payment account. Then a data-protection review of what personal information is held and who can reach it, the payment integration brought to a current supported version, dormant accounts removed, and a modest care plan sized to what a charity can genuinely sustain.
What changes: Income keeps flowing without a nervous migration, the trustees have a defensible answer on data handling, and the organisation is no longer one forgotten renewal away from losing its own domain.

03 · Property & lettings

The agency closed and took the passwords with it

The problem: The portal that syncs listings to the major property sites was built and hosted by an agency that has ceased trading. Nobody has the source code, the hosting invoices are being paid to a company that no longer answers, and listings have started failing to publish.
What we build: Recovery of what could be recovered directly from the running server, an honest assessment of what was unrecoverable, immediate stabilisation of the failing feeds, migration to hosting in the client's own name, and a costed comparison between maintaining the recovered system and replacing the portal outright.
What changes: The listings publish again within days, the business is no longer dependent on a defunct supplier's infrastructure, and the replace-or-keep decision is made with real numbers rather than under pressure.

The technology

The tools behind it, named

We do not get to choose what we inherit. That is rather the point. These are the tools we use to work out what you have and to get it somewhere stable.

6 layers · 31 technologies

Working out what you actually have

Reading an unfamiliar system quickly: what it depends on, what is dangerously out of date, and what the code is genuinely doing versus what everyone believes it does.

GitHub
SonarQube
Snyk
Trivy
Mermaid

The stacks we most often inherit

Age is not the same as danger. These are the platforms behind most orphaned systems we are asked to adopt, and all of them can be supported properly.

WordPress
PHP
Laravel
Node.js
React
.NET
Python

Databases we take over

Usually the part worth protecting most. First priority is a proven backup and a tested restore, before anyone changes anything at all.

MySQL
PostgreSQL
MongoDB
SQLite
Redis

Getting it off one person's laptop

Turning an environment that exists only in somebody's memory into something reproducible, deployable and describable in a document.

Docker
GitHub Actions
Terraform
Ansible

Locking it down before anything else

Credentials into a vault you own, certificates renewing themselves, and a layer in front of the application while the deeper work is still under way.

1Password
Bitwarden
Let's Encrypt
Nginx

Where it ends up living

Somewhere supported, in accounts registered to your organisation, priced honestly against what the system genuinely needs.

Hetzner
DigitalOcean
Google Cloud
Cloudflare
Ubuntu
Debian

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

Adoption runs in a fixed order, and the order matters. You cannot safely improve something you cannot yet restore.

The amnesty conversation

Tell us what you do not know. Which accounts you cannot get into, which emails bounce, what the last developer never explained. Nobody is judged for any of it, and the unknowns shape the plan far more than the knowns do.

Access recovery

Getting your organisation named as the owner of every domain, host, repository and service. Where credentials are genuinely lost this means provider recovery processes, proof of entitlement and patience, and it is frequently the longest part of the whole engagement.

The health check

Code quality, dependencies and known vulnerabilities, hosting and its support status, data and backups, and how much of the system is understood at all. You get a written report with a rating, the risks ranked, and a recommendation we are prepared to defend.

Stabilise what is dangerous

The ranked risk list, worked through in order, before any feature discussion. Backups first, then anything publicly exposed, then anything that would be unrecoverable if it failed tomorrow. Small, careful, reversible changes only.

Rebuild the safety net

Version control you own, a staging copy, a scripted deployment with rollback, monitoring on the journeys that matter, and backups proven by restoring them and timing how long it took.

Document, then adopt

Diagrams, runbook, account register and recovery procedures written up and handed over. At that point it stops being a rescue and moves onto a normal care plan: patching, monitoring, an SLA and monthly improvement hours like anything else we look after.

Before you commit

The questions worth asking

We do not have the source code. Is that fatal?

Often not. For most web applications the running code is on the server and can be recovered from there, put into version control and worked with normally. It is genuinely fatal in a few cases, compiled applications with no source, a repository deleted along with the account, a build step nobody documented that cannot be reconstructed. We establish which situation you are in during the health check, before you have committed to anything beyond it.

Will you tell us to rebuild it?

Sometimes, and we will show the working rather than asserting it. Our default preference is genuinely to keep a working system alive, because a rebuild is expensive, risky and throws away years of accumulated business rules that nobody has written down. But when a platform is out of support with no upgrade path, or when patching costs more each year than replacement would, saying so is the honest answer even though it is the more expensive one to hear.

How much does adoption cost?

The health check is a fixed piece of work with a fixed price, and it exists precisely so the rest can be quoted from evidence. We will not give you a firm figure for stabilisation before it, because inherited systems sometimes cost significantly more to stabilise than they first appear. That is the honest risk of this work, and pretending otherwise is how these projects go wrong for everybody. After the health check you get a range, the specific unknowns that could move it, and stages you can stop at.

Our code is a mess and we are a bit embarrassed about it.

Nearly everyone says some version of this, and the code is almost never as bad as the owner fears. Software that has been earning money for years while nobody maintained it has already proved something important about itself. We are assessing risk, not marking homework.

The old developer still has access. What should we do?

Sequence matters here, because revoking access carelessly can lock you out of your own systems. We inventory everything first, make certain you have independent owner-level access to each account, then rotate credentials and revoke the old ones in a deliberate order, and monitor afterwards for anything that breaks because it was quietly using a key nobody knew about. Rushing this step is the most common way an already awkward situation becomes an outage.

Can you support it without inheriting the blame for it?

Yes, and the health check is what makes that possible. It records the condition the system was in on the day we took it on, including faults we have found and not yet fixed, so the starting point is a written fact rather than a matter of opinion later. We are accountable for what we do and for the risks we told you about; we are not going to pretend a decade of decisions we had no part in never happened.

Nobody left who knows how it works?

Tell us what you are running and what you have lost access to. We will do a health check, tell you honestly what condition it is in, and give you a plan with a fixed first step.

Start the conversation →

Explore more

The rest of Ongoing Care & Support

Security & updates Always-on monitoring A real response promise Continuous improvement ← All of Care