The cost of an application is not what it takes to build. It is what it takes to change five years later, under load, with the original team gone.
That is easy to agree with and hard to act on, because the build is the part with a budget, a deadline and a launch date attached. The five years afterwards have none of those. They arrive as a series of small requests that each seem reasonable and each take longer than anyone expected.
The bill arrives later, and it arrives every month
Most application estates contain at least one system that still runs the business and resists every change asked of it. It works. It is not going anywhere. And every quarter someone estimates a modest change to it, and the estimate comes back at three times what the same change would cost anywhere else.
Nobody decided this. It accumulated. Each individual shortcut was defensible under the deadline it was taken for, and the compounding was invisible until the team that held the context in their heads moved on.
The useful question is not whether an application is well built. It is how much the next change costs, and whether that number is going up or down.
Four things that make change expensive
In roughly the order we encounter them:
Boundaries that were never drawn. When no one decided where one responsibility ends and the next begins, every change reaches further than it should. A pricing tweak touches checkout, reporting and the nightly export, because all three read the same table directly. The cost is not the change; it is the regression testing around it.
Tests that describe the code rather than the behaviour. A suite that asserts implementation detail fails whenever the implementation changes, which is precisely when you needed it to hold still and tell you something. Teams learn to distrust it, then to skip it, and the safety net becomes a tax.
Interfaces that live in someone's head. An undocumented contract is a contract that can only be changed by the person who remembers it. That person is a single point of failure, and eventually a leaving date.
Deployment as an event. When releasing is slow and risky, releases get batched. Bigger batches are riskier, so they get rarer, so they get bigger. The loop tightens in the wrong direction until shipping anything requires a weekend and a rollback plan.
None of these are exotic. All four are cheaper to prevent than to remove.
Modernization without the rewrite
When an application finally becomes hard enough to change, the instinct is to replace it. It is an appealing plan: the problems are known, the new stack is better, and the estimate is always optimistic because nobody is estimating the parts they have forgotten the old system does.
The trouble is that a rewrite asks the business to accept a long period with no new capability, in exchange for eventually arriving back where it started. Most organizations cannot absorb that, and the ones that try often end up running both systems for years.
The alternative is less satisfying and works more often. Capability is carved out of the monolith one boundary at a time. Each piece is extracted behind an interface, proven in production alongside the original, and only then does the old path get removed. Every step is reversible. The business gets working software throughout, and the programme can be stopped at any point without leaving a half-migrated estate behind.
It is slower on paper. It is faster in practice, because it does not require anyone to be right about everything up front.
What we actually do
Three related areas, usually in combination rather than isolation:
Engineering. Custom web and enterprise applications, SaaS and product engineering, frontend, backend and API development, and the UI/UX engineering and design system work that stops a product fragmenting as it grows.
Architecture. Microservices and service boundaries, API-led integration design, application portfolio assessment, and technical debt reduction planned as a sequence someone can actually fund — not a list of grievances.
Modernization. Legacy and application modernization, incremental monolith decomposition, re-architecture and re-platforming, and ongoing application maintenance and support.
What it is supposed to buy you
Four outcomes, and they are the ones worth measuring:
- Faster, safer release cycles
- Lower cost of change on core applications
- Systems that integrate rather than duplicate data
- Reduced dependency on individual engineers
That last one deserves emphasis, because it is the one that gets quietly traded away. A team that can only be changed by the people who built it is not a capability. It is an exposure.
The horizon we build for
We engineer for the decade after go-live, not for the demo. In practice that means clear domain boundaries, tested code, documented interfaces and deployment automation — none of which is novel, and all of which is routinely skipped when a date is close.
It also means making trade-offs visible before they are committed to. Every architecture decision costs something. You should be told what is being accepted alongside what is being gained, while there is still a choice to make.
And what we leave behind should be documented well enough for your team to own it. If the work only remains maintainable while we are still involved, we have not finished the job — we have just moved the dependency.
If any of this sounds like the estate you are running, start a conversation. We will tell you what it would take, and whether we are the right team for it.
Written by VYLQORA. Have a view, or a problem this touches? Start a conversation.