The hidden cost of software that works — and why I fix it before it explodes

This week, I thoroughly reworked an application that had no bugs, no user complaints, and didn't gain a single new feature in the process. It's probably the most cost-effective piece of work I've done all year. Here's why.

The real problem: the cost of a change grows with the size of the application

A small internship-scheduling application for a medical faculty had been built fast, for a good reason: during discovery, the only question that matters is "did we actually understand the need?", not "is the code elegant?" Everything lived in a single, undifferentiated block of logic — the right call, at that stage.

But that choice has a cost, and it doesn't show up right away: it grows with the application. Changing a single detail — a doctor's availability, say — meant loading the entire block, understanding the whole context, and accepting the risk of breaking something else elsewhere, with no simple way to prove nothing else had moved.

And this problem hits a human developer and an AI agent equally. An agent can only reason correctly about a scope it can fully load and verify. Faced with an undifferentiated block of logic, it has to reload everything on every change — more room for error, less certainty about the result, and no mechanical way to check nothing else broke.

Why you never rewrite everything at once

The right answer isn't to rebuild everything in one go — too risky, too slow, and it takes the service offline. The right answer is to migrate one area at a time, and above all to put a safety net in place before touching a single business rule.

In practice, the method always follows the same order:

Measure before moving anything — map precisely what exists, without changing it.
Build the safety net — a set of checks that captures the application's current behavior in detail. Nothing gets moved until that net is 100% reliable: migrating without it is migrating on sand.
Extract area by area — each step is verified before moving to the next.
Lock it in — the checks become automatic and blocking, so the problem can't silently creep back.
Prove it, then have a human sign off — re-measure what was measured at the start to prove nothing regressed, and someone validates before the step counts as done.

On the first migrated scope: 16 out of 16 features moved, 170 automated checks proving the external behavior stayed identical, a full security audit re-run — and the application never stopped running during the operation.

What it changes for the price of your future changes

Here's the real payoff, the one that matters to you: once this work is done, changing one specific detail — a doctor's availability, in our example — only touches a small, well-defined area of the code, not the whole application. Whether the application has 10 features or 100, a well-scoped change costs roughly the same each time. The cost stops climbing with the size of the project.

It's also what makes delegating to an AI agent genuinely reliable over time: an agent can only work with confidence on a scope it can fully load and verify. An application built as a single block becomes, over time, structurally hard to hand to an agent — even a well-supervised one. An application split into verifiable areas, on the other hand, stays trustworthy at any size: that's what lets me scope the work and verify the result, instead of re-reading every line on every change.

Who decides what

I never act with a responsibility I couldn't answer for. Applied to this kind of work:

The AI agent executes and decides what is bounded and mechanically verifiable: how to structure a module, how to lock in existing behavior.
You decide what to build, in what order, for what need — never how the code is organized internally.
I step in on what actually commits us: the chosen scope boundaries, what stays or goes from the old code, decisions that are hard to undo. Those get validated at the decision point, not reviewed commit by commit.

Why the right time is now, not later

This kind of overhaul is cheapest while the application is still small: less code to secure, fewer areas to cover. If you wait until requests pile up, you'll end up doing this same work later — at the same time as new features, on a system already in real use, with your own users as the test net. That's exactly the scenario this method is meant to avoid.

What this means for your project

If your application was built fast to validate an idea — often the right call — the question isn't "should we rebuild everything?" but "how much will your next change cost in six months, if nothing changes between now and then?" If the answer isn't clear, that's the moment to talk about it — contact me and we'll look at it together.