For systems that
already exist.
Whoever built them. Most companies do not need a new system; they need a straight answer about what breaks first in the one they have — and what it costs to stop that happening.
02 — What we build
An outside read, or someone to carry the work forward.
From a two-week assessment to the continuous upkeep of a system already in production.
- Architecture review
- A written assessment of the system: what gives way first, why, what prevention costs and in what order it is worth doing. The document is yours and can be handed to anyone, including another firm.
- Second opinion
- You have a rewrite proposal or a technical plan and nobody independent to check it against. We read it and say whether it holds up, what it leaves out, and which questions are worth asking before signing.
- Modernising older systems
- A staged route out of an ageing system where every stage leaves the business working. Piece by piece, rather than a three-month freeze and a launch everyone hopes for.
- Maintenance
- Ongoing work on a live system: security updates, fixes, small changes, with an agreed response time and monthly reporting.
- Taking over a system with no team left
- When the people who built it are gone. We start by standing it up from scratch on a clean machine — the most honest test of what state it is in — and by writing the documentation that is missing.
What we useAssessment · staged modernisation · maintenance · takeover · second opinion
03 — When this is the problem
Signs this is where it hurts.
- The only person who understood the system has left the company.
- Every small change breaks something else, so changes get rarer and rarer.
- You have a proposal to rewrite everything and no way to judge whether it is justified.
- The system works, but runs on versions nobody patches any more.
- Nobody can say with confidence what happens if that server dies tomorrow.
04 — How we work
What the work actually looks like.
The deliverable is a document, not a meeting
An assessment leaves you with something written: findings and the order worth tackling them in. It can be read by management, by finance and by the next technical team, none of whom were in the room.
Replace in pieces, do not rewrite wholesale
The old system keeps running while parts move across behind the same interface. Slower on paper and far safer in practice: it can be stopped at any point without losing everything.
We say when there is nothing to do
Sometimes the conclusion is that the system is fine and the problem sits elsewhere — in a process rather than in code. We say it, even when that ends the conversation about a large project.
No client names, in either direction
What we learn about your systems stays with us, and what we learned about anyone else’s does not reach you. That is why you will not find named case studies on this site.
05 — Common questions
What people ask about this part.
What does an architecture review contain?
A written document: how the system is built today, what risks it carries and in what order to address them, with an estimate against each. We read the code, the database and the way it gets deployed, and we talk to the people using it daily — which is usually where the clearest findings come from.
Do you recommend rewriting from scratch?
Rarely, and never as the opening move. A full rewrite means months of paying for something you already have, plus the risk that the new system misses cases the old one had quietly handled for years without anyone writing them down. Replacing in pieces is almost always the better trade.
Can you work alongside our in-house team?
Yes, and on modernisation work it is the usual arrangement. Your team knows the domain and the history behind the decisions; we bring the time and the technical ground they do not cover. The aim is that the team can carry on alone afterwards, not that they depend on us.
Will you maintain a system you did not build?
Yes. We start with a takeover stage: standing the system up from scratch, writing the missing documentation and listing the immediate risks. Maintenance proper begins after that, so we are not promising a response time for a system we do not yet know.
06 — The other capabilities
They rarely arrive one at a time.
Each one leans on the next: an app needs a backend, the backend needs somewhere to run, and whatever is already running needs someone to keep it alive. We take the whole chain, or just the link that is missing.
07 — Next step
Got a system
nobody is sure about?
We will read it and tell you in writing where it stands — including if the answer is to leave it alone.