Why Does Business Software Get Harder to Change After Launch?

You asked for a small change to your own software, and the answer came back: six weeks. The change is simple. 

What makes it slow is that no one is sure what it will break, because the person who wrote that part is gone, the business rule behind it lives in someone's memory, and the last time your team touched that area, something unrelated fell over. 

So the change waits, and the workaround becomes permanent. Almost every company has one of these by now, the feature nobody will touch, usually with a nickname.

This is the part of software nobody sells you on launch day. Launch gets the demo, the announcement, and the celebration, and it deserves some of that, because delivering a working system is real. 

But launch is only the starting line. It proves the system can be built, and it says almost nothing about whether the system can survive being used. 

What happens over the next two years, when employees, customers, and managers actually depend on it, is the test that matters.

‍

What does launch actually prove?

Launch proves the system can be delivered, and not much more. A system can go live on time, look polished, pass its initial tests, and still be miserable to own six months later.

The default is easy to fall into because launch is the visible milestone. It has a date, a budget, and a room full of people who worked toward it. 

Maintainability has none of that. No one throws a party because the code is documented or the database was structured to handle next year's reporting, so the incentives pull everyone toward the demo and away from the day after it.

The gap shows up in ordinary moments: the interface looks clean but the backend resists every change, the feature works but no one wrote down the rule it depends on, and the report runs but every small adjustment needs a developer. 

Every one of those is an ownership failure that surfaces only once the system is in real use, well after launch looked like a success.

‍

Why is maintainability a business problem?

Because the cost of ignoring it lands on the business itself. 

A CEO has no reason to track test coverage or architecture in the abstract, right up until a small change takes six weeks, a customer-facing bug damages trust, or the company cannot pursue a new line of business because the system will not bend to support it.

McKinsey estimates that 10 to 20 percent of technology budgets meant for new products get redirected to servicing technical debt, and that debt makes up 20 to 40 percent of the value of a company's entire technology estate. 

Stripe's research put it in human terms: developers spend about 42 percent of their time dealing with debt instead of building. 

That is nearly half of what you pay your most expensive people to do, spent fighting decisions made years earlier.

We see the far end of this when a company arrives with a system that has become the thing everyone works around. 

ComplianceDashboard came to us on a 12-year-old system that was difficult for staff to use and couldn't scale, where the aging architecture was limiting growth and slowing every workflow. 

The platform still ran. It just could not change anymore, and a compliance business that cannot adapt to new regulations is a business in trouble. 

We led a complete platform re-architecture from the ground up, and the rebuilt system now sends over 20,000 emails per week on a stable, scalable foundation built for long-term growth.

‍

What are the warning signs software was built only to launch?

Nearly all of these are things a non-technical leader can feel without reading a line of code. 

If several are true, maintainability was probably not part of the original build:

• A small change requires a large investigation before anyone will commit to it.
• Only one person understands how a critical part works.
• Documentation is missing, outdated, or too vague to trust.
• The team avoids changes because something unrelated might break.
• New features keep introducing new bugs.
• Reports need manual correction every time.
• The system cannot easily connect to newer tools.
• The original developer or vendor has to be involved in every decision.

Usually it is the same story: the software was built to pass launch, and the day after was treated as someone else's problem.

‍

What does maintainable software require from the start?

Maintainability is designed in before anyone needs it, and by the time you need it, it is expensive to add. 

A few things have to be true from the beginning:

• Clear architecture that is built to absorb change as the business grows.
• Documented business rules, so the logic behind an important workflow does not live only in one person's head.
• QA that mirrors real use, testing whether the workflow holds under real conditions, beyond whether a single button works.
• A clean handoff, so the business is not stranded if a developer or vendor leaves.
• A sensible data structure that supports reporting and the changes coming later.
• Environment discipline, so changes are tested safely before they ever reach the live system.

That last one stopped being abstract in July 2024. CrowdStrike pushed a content update that had not been adequately tested, and it crashed 8.5 million Windows machines around the world within hours. 

Delta alone canceled 7,000 flights over five days, stranded 1.3 million passengers, and later sued over more than $500 million in losses, arguing that testing the update on a single machine first would have caught it. 

One skipped safeguard on the path to production, at one of the most sophisticated security companies in the world, and the bill ran into the hundreds of millions. 

Maintainability is the discipline that keeps a routine change from turning into that.

‍

Who owns the software after launch?

Someone has to, and when no one does, the system gets a little harder to improve every month. 

Post-launch software needs a real plan: who owns it internally, who decides which changes matter, how bugs get prioritized, how updates get tested, and how the documentation stays current as the business changes.

This is the part of the work we built our firm around. We host and maintain what we build, every project carries a two-month post-launch warranty, and a senior developer stays on your account instead of rolling off to the next thing the moment you go live. 

We believe that business is built on transparency and trust, and that good software is built the same way, and that is why we stay on the account long after launch, when most of the value of a custom system actually shows up.

Leland Little is what that looks like over time. 

In a business where every second of downtime is a lost bid, we modernized their commerce systems and then stayed. 

As their team puts it, we have become their technical backbone and support all of their major systems, and they now run multiple online auctions a week and have grown significantly. 

For them, maintenance is a standing partnership, with the same team that built the systems still running them.

‍

Should you maintain, refactor, or rebuild?

Not every maintenance headache means a full rebuild, and the fear that it does keeps a lot of companies frozen on systems that only need a tune-up. 

There are three honest paths:

• Maintain when the core system still supports the business and the issues are manageable.
• Refactor when the system still has real value but parts of the code, data, or workflow need cleaning up to support what is coming.
• Rebuild when the system no longer matches how the business runs and every new requirement turns into a workaround.

The right path depends on what the system still does well and where it holds the business back. 

The best time to protect yourself from this decision, though, is before the build even starts, by asking a prospective partner the questions that reveal whether they are building for launch or for the long run:

• Could someone who did not build this understand it later?
• Are the business rules documented?
• How will changes be tested after launch?
• Who owns the system internally once it is live?
• Which workflows are likely to change in the next year?
• What happens if the original developer is no longer involved?
• What does success look like six months after launch, not just on launch day?

A good software partner can answer these before a line of code is written. 

If those answers only show up after something breaks, that tells you how the system was built.

‍

What actually proves software was built well?

It shows up after launch, once real people depend on the system every day, in whether it can still be understood, maintained, improved, and trusted. 

Launch matters, but it is a starting line dressed up as a finish line. 

The companies that get the most from what they build treat maintainability as part of the build, part of the budget, and part of how they plan to keep running. 

Maintainable software gives you more than a working tool. 

It gives the business room to change without starting over every time something does.