The hidden cost of maintaining old products.
Every live product has an ongoing cost that never shows up in the original plan: the attention it takes to keep running.
Every shipped product carries an ongoing maintenance cost — support, fixes, dependency updates, quiet decay — that rarely appears in the original plan and never really goes away. Launch day gets all the attention, the celebration, the announcement. The years after it get the actual work, largely unremarked on, which is exactly why it’s so easy to underbudget for.
What “maintenance” really covers
Maintenance isn’t only bug fixes. It’s answering the same support question for the fortieth time because the interface never quite made the answer obvious. It’s updating a dependency before it becomes a security problem, a task that produces no visible improvement for users but has to happen anyway. It’s noticing that a workflow which made sense a year ago no longer fits how people actually use the product now, because their needs quietly shifted while the product stayed still.
None of these are dramatic on their own. That’s precisely what makes them easy to overlook when estimating what a product will actually cost over its lifetime — each individual task is small enough to seem like it barely counts, and the accounting rarely happens at the scale where the pattern becomes visible.
Why this cost is easy to underestimate
It’s easy to underestimate because it’s diffuse. No single week of maintenance looks expensive, viewed on its own. Multiplied across years and across every product a team runs simultaneously, it becomes one of the largest costs a small studio carries — larger, often, than building the thing in the first place, even though building is what gets budgeted for carefully and maintenance is what gets treated as an afterthought.
Part of the reason this happens is that maintenance cost is a claim on future attention, not present money, and future attention is much harder to plan for accurately than a present budget line. It’s easy to commit a team’s future selves to an obligation that feels manageable in the moment and turns out to compound.
Why we factor this in before we build
This is part of why we think carefully before adding a new product to what we run: not “can we build this,” but “are we willing to carry this for years, not just launch it once.” That second question changes the calculus considerably, because it forces an honest look at ongoing capacity rather than just the capacity needed for the initial build.
It also changes what gets built. A product that’s cheap to build but expensive to maintain over years is a worse bet than one that costs more up front but is genuinely simple to keep running — a tradeoff that’s easy to miss if the maintenance cost is never counted seriously in the first place.
Common questions
How can a team estimate maintenance cost before a product has even shipped? Look at comparable products the team has run before, and count the recurring categories honestly: support volume, dependency churn, and workflow drift as usage patterns evolve. Past products are the best available predictor.
Does adding more features always increase maintenance cost proportionally? Usually more than proportionally — each added feature is a new source of support questions, a new surface for bugs, and a new thing that can quietly stop fitting how people use the product over time.
What’s a sign that a product’s maintenance cost has become unsustainable? When the team spends more time keeping existing things running than building anything new, without a clear plan to change that ratio.
Takeaway: the true cost of a product isn’t what it takes to ship — it’s what it takes to keep alive afterward.