Taking over someone else's codebase.

Most takeover requests arrive as an emergency. The team that built the platform is gone, the one developer who understood it has moved on, and something just broke in production. The site still runs, mostly, but nobody left can safely change it. That is the moment people come looking for a new pair of hands.

We take that work. We do not take it blind.

The audit comes first, and it is paid

Before we quote a takeover, we run a fixed-fee audit - usually a week. Not a sales exercise dressed up as a favour, an actual read of the codebase: how it is structured, what it depends on, where the bodies are buried. You get an honest written answer to one question - can this be maintained as it is, or does part of it have to be replaced - and a number for each path.

We charge for it because it is real work, and because a paid audit keeps us honest. When the honest answer is “this is fine, keep it, here is the one thing to fix,” we are not tempted to invent a rewrite to justify a bigger contract.

What we are actually reading

A codebase tells you how it was built long before anyone explains it. We look for the same handful of signals every time:

• How much of it is someone else’s code. A short, curated set of dependencies is maintainable. Twenty-four plugins doing the job of one custom module is a warning, not a feature.
• Whether it can be run locally. If we cannot stand the project up on a laptop in an afternoon, neither can the next developer, and every change becomes a gamble against production.
• Where the logic lives. Business rules scattered across templates, a database, and three plugins are a rewrite waiting to happen. The same rules in one readable place are a Tuesday.
• What happens on update. A platform that cannot take a framework or a WordPress update without breaking is already on a countdown.

None of this needs the original team in the room. Good code explains itself. The absence of an explanation is itself the finding.

Rescue when we can, replace when we must

The default answer is rescue. Replacing a working platform is expensive and risky, and most of the time it is not warranted - the code is tired, not dead. We stabilise it, document what matters, and take over maintenance from there.

Sometimes it is dead. A build fighting its own foundations, where every fix costs more than the last, is cheaper to replace than to keep resuscitating. We will tell you that plainly, and we will not pretend a rewrite is an “optimisation.” If replacing it is the right call, we scope it as its own project, in the open.

After the takeover, it is the same hands

The point of a takeover is not to become the next team that ships and vanishes. Once we own a platform, the people who audited it are the people who maintain it. One email address, no ticket queue, no rotation. The whole reason a codebase ended up orphaned is the model we are built to be the opposite of.

If you are sitting on a platform nobody can safely touch, that is exactly the conversation the audit is for.