When a product stops changing, people assume it stopped mattering. The roadmap goes quiet, the changelog thins out, and eventually someone asks whether it's still maintained. We've started answering yes, and nothing is planned, and meaning it.
Behind that question is an assumption that software is a service you deliver continuously, and that a tool has to keep changing to stay worth anything. For some products that's true. For most of what we build, it's a habit borrowed from companies that are expected to grow in ways we aren't.
What each feature costs after it ships
What it costs to build a feature is the part you can see, and it's also the part that ends. What doesn't end is everything that feature now touches. Each new thing the product does has to keep working alongside everything it already did, through upgrades nobody asked for.
Building features adds up in a straight line. Maintaining them doesn't.
Where \(n\) is the number of things the product does. Shipping the tenth feature costs about what the ninth did. Maintaining it costs you nine new interactions, any of which can break, confuse someone, or need a migration. Double what the product does and you roughly quadruple what has to keep holding together.
This is the maths behind a pattern most people recognise: a small team ships quickly for two years, then slows to a crawl without anyone doing anything wrong. Nobody got worse at their job. The maintenance simply grew bigger than the team, and now every hour goes on keeping what already exists standing up.
Finished isn't abandoned
A finished product still gets security patches, still gets fixed when a dependency moves underneath it, still gets answered when someone writes in. What it doesn't get is new features. That difference matters, because people mix the two up constantly, usually the person asking for the new feature.
Deciding that a product is finished is a decision about \(n\), and it's worth making on purpose rather than discovering it when you run out of energy. It turns an open-ended commitment into a limited one: a small, known yearly cost to keep something working, for as long as it stays useful. It's the same trade we like in a domain, and the same reason the holding company suits us. The cost is capped and the time isn't.
How we decide
We ask two questions of a proposed feature. Does the product fail at its stated job without it? And would we still want it in the codebase in five years, when whoever asked for it has moved on? A request has to pass both. Most pass neither. They're genuine requests from real users, but they describe a different product from the one we built.
Saying no to those isn't really discipline, it's just arithmetic. Every yes adds permanently to the maintenance, and the team that stays small on purpose is the one who pays for it.
The products we're proudest of are the ones we haven't touched in a year and that still do exactly what they did when we stopped. They earn quietly, need almost nothing, and have never once come up in a planning meeting. In a portfolio we mean to hold for a decade, those are the ones carrying everything else.