Reducing Cloud & Maintenance Costs in SaaS

The previous parts modernized across the layers of a SaaS product, and at each one cost lurked in the background as a motive. This part brings it forward, because for the people who approve modernization, cost is often the language the whole case has to be written in. The trouble is that the cost of a legacy SaaS stack is mostly invisible on the one document everyone looks at — the cloud bill. The bill shows infrastructure spend, which is real but usually the smallest of three buckets. This part names all three, because you cannot reduce a cost you cannot see.

Bucket one: infrastructure that over-scales

The most visible cost, and the one a CFO points at first, is infrastructure — and a legacy architecture inflates it structurally, not incidentally. The mechanism is the one from Part 2: a system that only scales as a single block forces you to provision the whole thing to handle load on any part of it. You pay for capacity across the entire product to serve the demand of its busiest component. As you grow, the cost rises faster than usage, and the gap widens.

This is why attacking the cloud bill directly — cheaper instances, reserved capacity, a procurement renegotiation — produces only marginal relief. The waste is in the shape of the system, not the price of the compute. An architecture that could scale its parts independently would provision each to its own demand; the legacy one cannot, so it over-provisions by design. Reducing this cost durably means changing the architecture, which is modernization, not procurement.

Bucket two: legacy licensing

The second bucket hides in plain sight: the licensing on aging proprietary components, especially databases and middleware. Legacy commercial database engines and integration layers often carry fees that scale with capacity — cores, nodes, data volume — so as the product grows, the licensing climbs with it, on a contract structured to make leaving expensive. This is the vendor lock-in cost expressed as a recurring line item: you keep paying not because the component is the best choice today but because the switching cost has been engineered to feel higher than the bill. Modernizing the data engine or middleware to a stack without those terms — the engine modernization from Part 7 — removes a cost that would otherwise climb forever.

Bucket three: engineering capacity, the cost no one invoices

The largest cost of a legacy SaaS stack is almost always the one that never appears on any bill: the engineering capacity consumed keeping the product alive rather than moving it forward. A debt-heavy product spends a rising share of its team on firefighting, dependency upgrades, working around the architecture, and re-doing by hand what a modern stack would do for free. Stripe’s 2018 Developer Coefficient put the time lost to technical debt and bad code at roughly 42% of developer capacity — close to half the most expensive resource a SaaS company has, spent fighting the codebase.

This dwarfs the other two buckets in most SaaS companies, because engineering payroll is typically far larger than the infrastructure and licensing bills combined. Yet it is the cost most often left out of the conversation, precisely because it has no invoice — it shows up as a slow roadmap and a tired team, not a line item. Naming it is the single most important move in costing a legacy stack honestly. It is the team-level face of the keep-the-lights-on ratio: the share of capacity going to the past instead of the future, and the share modernization is meant to win back.

What modernizing actually returns

Modernization addresses all three buckets, and it is worth being precise about how each return arrives, because they are not the same.

Infrastructure savings come from an architecture that scales its parts independently, so you provision to real demand rather than to the whole. Licensing savings come from retiring the proprietary components whose fees climb with capacity. And the largest return — recovered engineering capacity — comes from lowering the share of the team consumed by keep-the-lights-on work, so more of next quarter’s capacity points at the roadmap. That last return is the one that compounds, because recovered capacity ships features that earn revenue, which is why it usually dominates a serious cost case even though it is the hardest to put a clean number on.

A note on framing the recovered capacity: it is most honestly presented not as “modernization will cut payroll” — it rarely does, and shouldn’t, since the goal is to redirect the team, not shrink it — but as the same team getting more of its time back for building. You are not spending less on engineering; you are getting more product out of the engineering you already pay for.

Measure your own buckets

The discipline that keeps a cost case credible is to measure your own three buckets rather than reach for an industry average. Your infrastructure cost and its growth curve are knowable from your own bills. Your legacy licensing is on your own contracts. Your engineering-capacity drain is estimable from your own delivery data — how much of the team’s time goes to keep-the-lights-on versus building. The legacy cost calculator is a starting point for sizing this across the buckets, but the number that survives a CFO’s scrutiny is the one built from your own figures, presented as a defensible range with stated assumptions. Industry stats like Stripe’s 42% establish that the problem is real and large; your own numbers establish that it is yours.

Where cost savings get oversold

Cost reduction is the most over-promised benefit in modernization, and overstating it is how a business case loses the room. The savings are real only where the spend being displaced is real, large, and attached to systems the business needs to keep. Modernizing a system that is already cheap, small, and stable to chase a cost saving will cost more than it returns — the savings live in the expensive, growing parts of the stack, not everywhere. And the returns take investment before they arrive: modernization spends money up front to lower a cost later, so on the wrong target it may never pay back. The credible cost case is specific about which buckets are large and climbing, honest that the engineering-capacity figure is an estimate not a guarantee, and clear that it does not apply to systems whose cost is already small.

Where this leads

We have now seen the full picture a SaaS company needs: the problem (debt as a tax on the product), the diagnosis (outgrown architecture), the tension (debt versus velocity), the method (slice by slice, no freeze, parity-validated, across every layer), and the cost it all turns on. What remains is to put it in front of the people who decide. Part 9, Pitching Modernization to Your Board, assembles everything into the business case that gets modernization funded — and into the de-risking story that matters most when a raise or an acquisition is on the horizon.