Custom software has a pricing problem. It's almost always quoted at the cost of the build — the upfront engineering, the design, the deployment — when the actual cost of owning custom software is the years that come after. Most clients learn this the hard way.
We talk about it openly because it's the single biggest reason people give for not building custom software in the first place. We'd love to have a tool that does X, but we don't want to be on the hook for maintaining it forever. That's a reasonable thing to say. It's also a thing that's quietly stopped being true.
Why maintenance gets expensive.
The build is the easy part. You scope it, you ship it, and on day one everyone is happy. The problem starts the day after.
Software does not sit still. The browser you targeted deprecated a feature. The payment provider you integrated changed their API. The cloud platform raised prices on the runtime you picked. The library you depended on got a security advisory. None of these are emergencies on their own. All of them together are why a piece of software that worked perfectly when it shipped needs someone paying attention to it three years later.
The cost of that attention is the part nobody quotes you up front. It's small per change but continuous, and it requires someone who understands the code well enough to make safe modifications. That person, historically, has been the same expensive engineer who built it — or someone who has to spend two weeks reading their work before touching anything.
Simple projects don't stay simple.
Here's the other thing that drives maintenance cost: scope creep, but not the obvious kind. The kind that comes from real life.
A clean little internal tool ships in week one. By month six, ops has asked for three small features, finance needs an export, and someone needs SSO because the company added a security policy. Each request is reasonable in isolation. None of them came up during the initial scoping. By the time they're all in, the codebase is twice the size it started at, the original architecture has been bent in three places to accommodate things it wasn't built for, and the next person who touches it has to figure out which decisions were intentional and which were accidents.
This isn't a planning failure. You can't plan for changes the world hasn't asked for yet. It's just what happens when software exists long enough to be useful.
And then there's the vendor problem.
Switching the firm that maintains your custom software has historically been a nightmare. The old firm had two years of context that lived mostly in their heads. The new firm has to rebuild that context from a partial readme and a codebase that's been touched by four different developers, two of whom no longer work there.
The result, as anyone who has been through it knows, is that switching costs you weeks before the new team can confidently make changes. So most clients don't switch, even when they should. They stay, because the cost of leaving is higher than the cost of being mildly unhappy.
That dynamic — staying because leaving is too painful — is the thing custom software clients have feared for thirty years. It's a fair reason to be skeptical of custom software in the first place.
What AI actually changes.
The biggest shift in our work over the last year isn't that AI writes code faster. It's that AI reads code faster. Specifically, AI can pick up an unfamiliar codebase — one written by someone else, in a style we wouldn't have chosen, three years ago, with sparse documentation — and produce an accurate map of what it does and how the pieces fit together. In hours, not weeks.
That's a change in the shape of the problem.
Reading existing code has always been the slow, expensive, error-prone part of maintenance. Every change starts with understand what's already here — and that step is where the bulk of the hours go. Writing the actual change is comparatively quick, once you know what you're touching.
When the read step gets dramatically cheaper, every other maintenance task gets cheaper too. Picking up an inherited codebase isn't a six-week onboarding anymore. Making a small change you've never made before isn't an afternoon of archeology. Refactoring something fifteen layers deep isn't a week of careful tracing.
The expensive part of maintenance was never typing the new code. It was understanding the old code well enough to safely add anything to it. That part is suddenly fast.
What this means for clients.
A few things follow from this, and they're worth saying plainly.
First, the total cost of owning custom software is going down — not just the build, but the years after. The maintenance arithmetic that used to argue against building custom is shifting. Things that were uneconomical to own a year ago are economical now.
Second, switching vendors isn't the trap it used to be. A new firm can be productive on an inherited codebase in a fraction of the time it used to take. That changes the negotiating position of anyone currently sitting on custom software they're vaguely unhappy with — the lock-in is softer than it feels.
Third, the small-feature backlog that used to pile up unanswered is answerable again. The reason it piled up was rarely that the items weren't worth doing. It was that touching the codebase to add them was disproportionately expensive relative to the value each one delivered. When that cost drops, the backlog moves.
What we do with this.
Most of the work we do lives in this space — picking up existing software, making it legible, making changes to it confidently, and handing it back in better shape. Some of it is software we built ourselves. A lot of it is software somebody else built and we're now responsible for.
We're comfortable taking that on now in a way we wouldn't have been three years ago. That's not bravado. It's that the tools have changed enough that the read step — the part that used to gate everything else — isn't the bottleneck anymore.
If you've been sitting on custom software you're nervous to touch — your own, or something you inherited — the right move is probably not to ignore it for another year. The arithmetic has changed. It's worth a fresh look.