01
The situation
Fix what you have
It works, mostly. Everything about changing it is getting harder.
Every change takes longer than the last one. Every quote is higher than the last one. Nobody can tell you why, or the answers you get are technical enough that you cannot tell whether they are reasons or excuses.
Or something sharper has happened, and the people who built it are gone.
02
Rescue
If your provider has walked away.
This is the situation we see most often, and it is more recoverable than it feels on the day.
You may not know where the software is hosted. The repository may not be in your hands, and the domain may be registered to somebody who no longer answers email. None of that is unusual, and none of it is a reason to rebuild.
We are a small engineering team, so we are not going to promise you a dramatic emergency response we cannot staff. What we will do is bounded and specific. Answer the health check and we will write back with what we can see from your answers, what we would need access to in order to see more, and what the realistic options are. If it is urgent, say so in the first question and it moves up the queue.
03
Recognition
What this usually looks like.
The original developers are gone and nobody understands the code
There is no documentation, or there is documentation that describes a version from three years ago.
It is slow, and getting slower
Reports that used to run in seconds time out. The database has grown and nothing about how it is queried has changed with it.
Every release breaks something else
There are no tests, or there are tests nobody trusts, so every deployment is an act of faith performed on a Friday afternoon.
It costs too much to run
The hosting bill grows and no one can point at what is driving it.
You have been told it needs a rewrite
And you do not know whether that is true, or whether it is the answer that happens to suit whoever gave it to you.
04
Approach
What we do about it.
We start by finding out what you actually have: the systems, the accounts, the hosting, the repositories, the data, and the people who still know something. Most of the work in a bad situation is establishing what the situation is, and most of the panic comes from not knowing.
Then we take a position, in writing, on the question you actually want answered, which is whether this is worth saving.
05
The position
Our position on rewrites.
A rewrite is usually the wrong answer, and we will tell you when it is. A rewrite throws away every undocumented business rule the current system has accumulated, and those rules are the asset. They are also invisible, which is why rewrites overrun: the estimate covers the features somebody listed, and the overrun comes from the ones nobody knew about until a customer complained.
Most systems we inherit are not broken. They are undocumented, untested, and unowned, which feels identical from the outside and is far cheaper to fix. Stabilise it, characterise the behaviour with tests, document what is there, then change it in pieces while it keeps earning money.
A rewrite is the larger invoice, so we are arguing against our own short-term interest here. When a rewrite genuinely is the right answer we will say which part, in what order, and what it costs to run both systems during the transition.
07
What you get
What you get.
A map of what you own
Systems, hosting, data, accounts, domains, and who controls each one.
A codebase inheritance document
What it does, how to run it, how to deploy it, and where it is fragile. The knowledge stops living in one person’s head.
A written read on what is wrong
Separated into what will break, what is expensive, and what is merely ugly.
Costed options
With the trade-offs stated, including the option of doing nothing.
Tests before changes
If we execute: the existing behaviour gets pinned down before anyone changes it.
A deployment pipeline
Which removes the Friday-afternoon ritual, and usually changes how a team feels about its own software.
08
Commercially
How it works commercially.
The assessment is the usual entry point, because the honest answer to what this costs to fix cannot be given before someone has looked. Fixed fee, fixed duration, written report, costed options. You keep the report whether or not we do the work.
After that, remediation runs as Scoped Delivery where the work has a definable end, or as an Embedded Function where it is genuinely open-ended and you would rather have capacity than a scope document.
You own what you pay for.
Including everything we document about a system we did not build.
09
Objections
The questions people ask us here.
Our previous provider will not hand over access. What then?
More common than you would think. A great deal can be established without their cooperation, from the running system, the DNS records, the billing accounts, and the people still in your business. We will tell you what we can determine without them and what genuinely requires them, so you know what is worth fighting for.
We have no documentation at all.
Then producing it is part of the work rather than a prerequisite for it. Nobody has ever failed our health check for not knowing the answers.
How do we know you will not just tell us to rebuild?
We have written the opposite position above, in public, where you can hold us to it. The assessment is also a fixed fee, so recommending a bigger project does not pay us more for the assessment itself.
Can you do this under NDA?
Yes.
What if the answer is that it does need a rebuild?
Then you get that in writing, with the reasoning, and with a sequence that keeps the current system alive while the replacement is built.
Claer & Volker
453 Winifred Yell St, Garsfontein
Pretoria, South Africa
info@claervolker.com
© 2026 Claer & Volker
·
·