Codebase assessment
A written assessment of what you have — the real risks, what is load-bearing, what is dead, and what it would cost to change. You keep the report whether or not you continue with us.
Service 04
Modernization & Ongoing Care
Someone else built it and they are gone. We make it safe to change again, and then we stay to maintain it.
01You are probably here because
Symptoms
- “The developer who built it is gone and nobody understands the code.”
- “It works, but we cannot deploy without holding our breath.”
- “Every new feature takes three times longer than it should.”
02What we actually do
The work, described properly.
Codebase takeover
We inherit systems whose authors have moved on. The first milestone is always getting it building, deploying and under test, before changing any behaviour.
Test and deployment safety net
Characterisation tests that pin current behaviour, then a pipeline that runs them. This is what makes every later change cheaper.
Incremental modernization
Strangling the risky parts one at a time behind a stable interface, so the system keeps earning while it changes.
Ongoing maintenance
Dependency updates, security patches, monitoring and a monthly written report. The people who did the work are the people who maintain it.
03Our approach
How we approach it
How we approach it
Inheriting a system is mostly an archaeology problem. The code tells you what it does; it rarely tells you why, and almost never tells you which parts somebody depends on in a way nobody wrote down.
So we do not start by changing things. We start by making the system observable and reproducible: getting it building on a clean machine, getting a deployment that is not a sequence of remembered steps, and pinning current behaviour with tests.
The hard parts we take a position on
Get it building before you get it good. A system you cannot deploy confidently cannot be improved safely, because you have no way to tell whether your change or the deployment broke it.
Characterise before you refactor. Tests written against current behaviour — including the behaviour that looks like a bug — are what let you change code you do not fully understand. Some of those bugs are load-bearing.
Rewrites are a last resort, and we will argue against yours. The second system is rarely simpler, and during the rewrite you are paying for two systems while shipping no new value. Strangling the risky parts incrementally is slower to describe and far faster to deliver.
04Technology, and why
Defaults, not dogma.
- Characterisation tests
- You cannot safely change code whose current behaviour is undocumented. These pin it first.
- Infrastructure as code
- A deployment that only exists in one person's memory is an outage waiting for a holiday.
05Related work
Where we have done this.
Taking over an abandoned codebase for a B2B SaaS team
An undocumented service whose authors had left, brought back under test and deployable on demand without a rewrite.
FAQQuestions we get
Questions we get
Should we just rewrite it?
Usually not, and we will tell you when the answer is yes. A rewrite trades a known system with known problems for an unknown one, and it typically takes far longer than estimated because the old system's behaviour was never fully documented.
What if the code is genuinely bad?
Most inherited code is not bad so much as undocumented and untested. We find out which it is during the assessment, before anyone commits to a direction.
Can you maintain it long term?
Yes, that is the point of this service. The alternative — a different team each time something breaks — is how systems end up unmaintainable in the first place.
Often paired with
—Modernization & Ongoing Care
Discuss a modernization project.
Tell us what is happening. We will reply with a real technical question, not a calendar link.
- 01
Send a short brief
Five minutes. What you are building, or what is broken.
- 02
We reply within one business day
From an engineer, with a real question or observation.
- 03
A 30-minute technical call
Free, no deck, no obligation.