Nobody's Calculating the Real Cost

Everything your team builds has two prices. Your organization is only looking at one of them.

The first price is the build. Requirements, design, sprints, launch. It's visible. It lives on a roadmap. It has a timeline and a team and a budget somebody approved. Executives love this number because it feels knowable.

The second price is everything after. Adapting it when the market shifts. Fixing what breaks when a dependency updates. Deciding — months or years later — whether to keep feeding it or let it die.

Maintenance consumes 60-80% of total software lifecycle cost. The build is the minority of the bill.

The build is the down payment. Maintenance is the mortgage. Your leadership team approved the down payment. Nobody calculated the thirty-year note.

This is a strategic clarity problem. Not an engineering problem. Not a process problem. A what-are-we-actually-committing-to problem.

The Half-Truth in Every Business Case

Here's why this keeps happening: maintenance never appears in a pitch.

When your team proposes a new product or feature, they present the build cost. Engineering hours. Design capacity. Timeline to launch. The decision-makers evaluate what they can see.

Nobody in that room is asking: what does it cost to keep this alive for three years?

Not the on-call rotations. Not the engineer spending 20% of their time patching something that was supposed to be a quick win. Not the opportunity cost of maintaining something mediocre instead of building something good. Not the PM stuck in constant triage mode because half the backlog is life support for zombie projects nobody will kill.

That cost is real. It's just invisible at the moment the decision gets made.

I learned this the hard way. Early in my career, I built an internal tool to solve a workflow problem. Took a weekend. People started using it Monday. Within a month, three teams depended on it. Within a quarter, it was breaking regularly, I was the only one who understood it, and I was spending more time maintaining it than doing my actual job. Nobody had asked for a maintenance plan because nobody — including me — thought it needed one. It was just a quick fix. Until it wasn't.

That tool cost more to unwind than it cost to build. And I see product leaders making the same mistake at scale every week — not with weekend projects, but with products they're presenting to the board. A product bet without a maintenance estimate is a half-truth dressed up as a business case.

Cheaper to Build, Easier to Ignore

This isn't a software problem. A hospital system I worked with launched a patient intake redesign — estimated at six months of staff training and workflow changes. Nobody estimated the three years of parallel process support, ongoing compliance updates, and retraining cycles that followed. They're still paying for it. The mortgage shows up in every industry where people build things and walk away.

Now add AI to this equation. Vibe coding — using AI to generate working software through natural language prompts — made the down payment so cheap that organizations stopped thinking about the mortgage entirely.

When you can prototype in an afternoon, "let's just try it" becomes the default. But every experiment that touches a customer or connects to a system creates a maintenance obligation nobody priced. Before AI, build cost was a natural filter. Three months and four engineers forced you to think hard about whether something was worth it. That friction forced strategic conversations.

Now the friction is gone. And so are the conversations. Organizations are signing thirty-year notes like they're lunch receipts.

Three Signals You're Flying Blind

The strategic question isn't "should we build faster?" Obviously yes.

The question is: does your organization have visibility into the total cost of what it's committing to?

Three signals — and they're all measurable:

Check your build-to-maintain ratio. Pull your engineering team's last quarter of work. What percentage went to new features versus maintaining, fixing, or patching existing ones? Industry benchmarks say healthy teams spend 20-30% on maintenance. If you're above 50%, your past decisions are eating your future capacity. Most leaders I talk to have never looked at this number. That's the problem.

Count your unowned products. How many things in production right now have no designated owner — no single person accountable for its health, its roadmap, its eventual retirement? Not a team that "kind of" watches it. A named owner. If you can't produce that list in five minutes, neither can anyone else. That's how things rot.

Measure your roadmap's honesty. Look at every line item on your current roadmap. How many include a maintenance cost estimate alongside the build estimate? How many have a declared lifecycle — prototype, pilot, or permanent? If the answer to both is zero, your roadmap is a down-payment ledger. The mortgage ledger is somewhere else — usually in the heads of frustrated engineers who can't get time to address it.

A product bet without a maintenance estimate isn't a strategy. It's a hope with a deadline.

If you're a PM, not a VP: You can start smaller. Track how much of YOUR time goes to maintenance versus new work this week. Count the Slack messages about things that were supposed to be temporary. That ratio tells you what's eating your capacity — and it gives you language for the conversation with your manager about why the roadmap keeps slipping.

Your Strategy Is Being Set by Inertia

Most organizations treat maintenance as an operational afterthought — something engineering handles after the real strategic work is done. That mental model is backwards.

Maintenance is strategic. Every product you maintain is a product you're choosing over something else. If you can't see that tradeoff, you can't make it deliberately. And if you're not making it deliberately, your strategy is being set by inertia, not leadership.

Product leaders who want strategic credibility need to make the invisible visible. Put the total cost on the table — not just the build, but the keep. Force the conversation your organization is avoiding.

That's not engineering's job. That's yours.

Prompt

Run these three numbers this week: your build-to-maintain ratio, your unowned product count, and how many roadmap items include a maintenance estimate. What story do those numbers tell about where your strategy actually lives?

Reply with your numbers — I read every response.

If this described your org, forward it to the person who needs to see it most.

Landed here from a friend? Subscribe here.