Your application has hit the limits of its technology
It works. It was a good choice. But every change costs more than the last, and some requests now get a technical answer where they were expecting a business one.
What you see
- Quoted lead times keep growing, for requests that look simple.
- You are told more and more often that the tool cannot do it, with no way of judging whether that is true.
- Performance degrades as volume rises, and workarounds get added.
- A single provider knows how to evolve it, and cannot be replaced overnight.
- Nobody dares put a date on the next big change any more.
What is actually going on
Every technology has a domain. A platform that lets you build fast, without writing code, is the right choice to get going: it trades power for time. That is an honest bargain, and it turns at the same place every time — when the application becomes the company's central system, and what is asked of it is no longer to start but to hold.
The ceiling does not announce itself with a breakdown. It announces itself in the price of changes. Each request works around a limit instead of using a capability, and each workaround makes the next one dearer. People call it debt, but it is not negligence: it is the normal cost of a choice that has run its course.
To that must be added something that has changed recently, and that changes the trade-off. Writing bespoke code used to be expensive — that was the main argument for closed platforms. That cost has fallen markedly since code came to be written with assistance, while the cost of a closed platform has not moved. A decision made a few years ago, on prices that no longer exist, deserves to be taken again.
What it costs you
A change budget that rises while the scope does not. Dependence on a single provider, which is not bad faith on their part but a fact: nobody else knows how the thing is put together. And above all, subjects that stop being proposed because the answer is known in advance. That is the dearest of the three, and it shows up on no accounting line.
How we go about it
We do not throw away what works. The first question at the scoping stage is what, in what already exists, deserves to be kept — and there is almost always something. On one such handover, the core of the application was already written in ordinary code: only the shell depended on the platform. The rebuild therefore covered the shell alone, not the business logic, which changes the pricing entirely.
Then we switch over piece by piece, with the old system still running. No big bang: on switchover day your teams are not discovering a tool, they have already been using half of it.
What you end up with
An application whose code belongs to you, delivered to your own repository, that another provider can take over. A separate test environment, and a regression suite replayed before every release — that is what makes it possible to move fast without breaking things.
And a written trajectory: what has been taken over, what remains, and what the next step would cost. You are not buying a dependency, you are buying an asset.
Where we have already seen this
The business application had reached the limits of its architecture, but its core was already running as ordinary code. Scoping priced the rebuild of the shell alone, and the work began without interrupting service.
The in-house tool, built without writing code, had become a bottleneck. Taken over module by module, with the old one left running until nobody opened it any more.
The questions we get asked
Do we have to stop everything during the rebuild?
No, and it is the first thing we check. Your current tool keeps running. We switch one module at a time, starting with the one that hurts most.
How do you know what is worth keeping?
That is what scoping is for, and it happens before any commitment. We look at what is code, what is configuration, and what is data. The first can be taken over, the third can be migrated — and it is usually the second that costs.
What if we want to change provider afterwards?
You can. The code is in your repository, the hosting is in your name, and there is no component of ours inside it. That is written into the contract, not promised out loud.
So the original choice was a mistake?
No. It was often the right choice when it was made: getting live quickly was worth more than anything else. What has changed is the relative prices. A trade-off is revisited when its assumptions stop holding, not when it becomes unfashionable.
The other situations
- Re-keyingThe same order gets typed in three times
- Edge casesThe moment a case falls outside the rules, the front line improvises
- Business rulesYour business rules live in a spreadsheet nobody dares touch
Tell us what your tool can no longer do.
Thirty minutes are enough to know whether a bespoke tool is justified, what it would cost, and how long it takes to pay for itself. If the answer is no, we tell you that too.
Book 30 minutes (new tab)