MOD
Legacy modernisation and rescue
It works. Nobody knows why. That is the problem.
The short version
Taking over a platform somebody else wrote and nobody currently understands — stabilising it, documenting it, and making it safe to change again.
A working system built by a developer who has since moved on is one of the most common situations in business software, and one of the most quietly dangerous. It runs. Nobody knows why. Nobody will touch it. And the cost of that grows every month.
What is included
Concretely, this is the work.
- Written assessment of what exists — architecture, dependencies, data model, risks, and what it would cost to fix each one
- Getting the system into version control, into a repeatable deployment, and out of one person's laptop
- A characterisation test suite that captures what the system currently does, so changes can be made without breaking it
- Dependency and runtime upgrades on unsupported versions that are quietly a security problem
- Incremental replacement of the worst parts rather than a full rewrite, where a rewrite is not justified
- Adding AI capability to a stable existing platform without rebuilding it
- Documentation and handover so the next person is not in this position
Approach
What you should expect to change
- A clear, written picture of what you are actually running
- Changes that can be made without holding your breath
- The bus-factor problem removed
How we take over a codebase
The first forty-eight hours are archaeology, not engineering. Get it running locally. Read the data model, because the data model is the truth and the code is an opinion about it. Find out what breaks in production, how often, and what people do about it.
Then we write it down — one document, honest, covering what is sound, what is fragile, what is dangerous, and what each of those costs to address. That document is a deliverable in its own right and it is yours whether or not you use us for the work.
On rewrites
We usually argue against them. A rewrite throws away years of accumulated edge cases, most of which nobody wrote down and all of which existed for a reason. Repairing and incrementally replacing is slower to describe and faster to deliver. We recommend a rewrite when the platform is structurally unable to do what the business now needs, and not because it is unpleasant to read.
Questions about legacy modernisation and rescue
We do not have the original developer or any documentation. Is that a problem?
It is the normal case, not an unusual one. The code and the database are enough. Anything you do have — old emails, a half-finished spec, a list of known bugs — makes it faster, but nothing is a blocker.
Will you criticise whoever built it?
No. Almost every system that looks bad was built under constraints that made sense at the time, usually a deadline. We describe what would need to change and what it costs. That is more useful to you and it is a better way to work.
Also
Other things we build.
AI agents and workflow automation
Agents that carry a whole process end to end — reading the enquiry, checking availability, drafting the quote, escalating the parts a person should see.
Read more BKGBooking and reservation platforms
The system your revenue actually passes through — search, availability, quoting, payment, confirmation, amendment, cancellation. Built to survive the edge cases.
Read more OPSOperations and back-office systems
The platform your team lives in all day. Suppliers, jobs, staff, documents, margins, reporting — shaped around how you actually work rather than a generic template.
Read moreStart a conversation
Have a project like this?
Send us a paragraph describing what the system needs to do and what you are using now. We will come back with an honest view of whether it is a fit and roughly what it costs.