Maintenance is product work

Most of a product's life happens after launch. A product that ships in six months and runs for six years spends more than ninety percent of its life in what most budgets call maintenance. Treating that time as a cost to minimize is how software quietly degrades, and how the improvements users would have valued most never get made.

The accounting problem

Building is a project. It has a start, an end, a budget, and someone who is proud of it. Maintenance is a line item. It has a monthly figure that someone tries to reduce every year.

This framing makes a strange claim: that the product was finished at launch and everything after is upkeep. No product that has users is finished. Users find the edges. The market moves. Dependencies change under it. The business learns what it actually needed, which is never quite what it specified.

The work that responds to all of that is product work. It happens to occur after launch.

What maintenance actually contains

When we maintain a system, the work falls into four kinds, and only one of them is what the word suggests.

Keeping it running. Dependency updates, security patches, certificate renewals, backup verification, capacity, incident response. This is upkeep, and it is not optional. Skipping it is borrowing at a high interest rate.

Keeping it correct. Fixing bugs, yes, but mostly noticing where the software's behavior has drifted from what users need. Reports that used to be right. Integrations whose other side changed. Edge cases that became common cases as the business grew.

Keeping it changeable. Removing complexity that no longer earns its place. Simplifying the parts that every change has to pass through. Improving tests and deployments so that the next feature costs less than the last one. This work is invisible in the product and decisive for its future.

Making it better. Small improvements informed by real usage: a faster page that people visit every day, a form that fails less often, a workflow with one step fewer. These are the highest-return changes in most products, and they are only visible to someone who is paying attention after launch.

A maintenance budget that covers only the first kind produces software that runs, drifts, hardens, and eventually gets rewritten.

Why this matters for who does the work

If maintenance is upkeep, it can go to whoever is cheapest. If maintenance is product work, it needs people who understand the product and its users, and who are trusted to make decisions.

We think the second view is correct, and it changes how we work. The people who maintain a system are the people who know it best. They should be the ones proposing what to build next, because they see where the friction is. They should have authority to remove things, not only to add them. And their time should be protected from being consumed entirely by the first kind of work, because the other three are where the value is.

What we do about it

When we take responsibility for a system, we plan maintenance as a product function. Upkeep is scheduled and boring. A share of every month goes to keeping the system changeable. And we keep a short list of small improvements drawn from real usage, worked through steadily.

The result is a system that gets better with age instead of worse, and a business that never has to fund a rewrite to buy back the years it spent minimizing the maintenance line.

The position

Launch is the beginning. Budget, staff, and pay attention to the years after it as the product work they are, and most of the reasons for rewriting software go away. This is the shape of software maintenance as AL+ practices it.