The Business Case for Software Performance: Six Ways Speed Makes You Money

TL;DR: A faster app costs less to run, converts more visitors, retains more users, ranks higher in search, defers your next infra migration, and lowers your engineering tax. The public studies are e-commerce, but the mechanism is the same for any SaaS. It just shows up in renewals, retention, and gross margin instead of a one-shot checkout funnel.

”Make it faster” is not an engineering request

Most teams treat performance as a quality-of-life thing engineers ask for when they’re bored, or a fire they fight only when something falls over. That framing is why it never gets prioritized: it competes with features, and features always win.

The reframe that actually gets it funded: performance is one of the few levers that moves cost and revenue in the same pull. Cut feature scope and you save money but lose revenue. Add features and you grow revenue but add cost. Make the existing product faster and both numbers move the right way. There are not many levers like that.

One caveat first. This is not an argument for optimizing early. If you’re pre-product-market-fit (an MVP, a prototype, a startup still hunting for customers), premature performance work is a classic waste. Ship, learn, find out if anyone wants the thing. Slow-but-shipped beats fast-but-nobody-uses-it every time at that stage.

Everything below applies once you’re in operations: real customers, real load, a cloud bill that arrives every month, churn you can measure. At that point performance stops being engineering hygiene and starts being a number on the P&L. Here are the six ways it pays, from most obvious to most overlooked.

1. Lower server cost: the direct one

Efficient software does the same work on less hardware. Cloud or on-prem, it doesn’t matter: fewer CPU-seconds, less memory, fewer instances, smaller database tier.

This is the angle people see first because it’s the easiest to measure. As a rule of thumb, an app with decent performance and architecture runs on roughly half the infrastructure of a careless one doing the same work. In extreme cases bad performance eats 10x or more: slow code gets papered over with bigger instances instead of fixed. The usual culprits are dull: N+1 queries, missing indexes, no caching so the same work is redone on every request, synchronous calls to slow third-party APIs sitting in the middle of the request path, a database doing a job it was never built for, and instances scaled up to hide all of the above. None of it touches a single feature. It’s pure margin sitting in the bill.

The trap: teams scale up to fix slowness because it’s faster than fixing the code. That works until the bill is the problem. Then you’re paying a recurring tax, every month, forever, for a one-time engineering job nobody did.

2. Faster pages convert better, with real numbers

This is the most-studied effect in the industry, because e-commerce can measure it directly. The classics first:

Amazon (2006-era internal test): every +100ms of load time cost ~1% in sales.
Walmart (2012): every 1 second of load-time improvement lifted conversions up to 2%.
Deloitte + Google, “Milliseconds Make Millions” (2020, 37 brands, 90% confidence): a 0.1s speed improvement raised retail conversions +8.4% and average order value +9.2%; travel conversions +10.1%; lead-gen form submissions +8.3%.

Read that Deloitte number again: a tenth of a second moved conversion by 8%+. Not a redesign. Not a new feature. A hundred milliseconds.

If those feel dated, the 2020s versions say the same thing louder:

Rakuten 24 (2022): a one-month A/B test where the only change was Core Web Vitals optimization. Revenue per visitor +53.4%, conversion rate +33.1%, average order value +15.2%, exit rate -35.1%.
redBus (2023): improved INP (Interaction to Next Paint, how fast the page responds to input) by 72%, and sales rose 7%.
Vodafone Italy: an A/B test where a 31% improvement in LCP (Largest Contentful Paint, how fast the main content loads) produced 8% more sales.
Google: bounce probability rises ~32% as load goes from 1s to 3s.

And the story at the top of this post, 8 seconds down to 500ms with conversion doubling, is mine. Same product, same traffic, same offer: the only change was that people stopped leaving before the page finished loading. The studies above scale that mechanism across dozens of brands and millions of sessions; I’ve watched it happen on a single product.

3. Speed keeps users: retention is the compounding one

A fast product is a pleasant product. People stay in tools that respond instantly and quietly abandon ones that make them wait. Conversion is a one-time event; retention compounds every month.

This matters more the more often people use your software. A checkout page loads once per purchase. An internal SaaS dashboard loads forty times a day per user. Every spinner is a small tax on someone’s workday, and it accumulates into “this tool is painful” long before anyone files a ticket about it. Slow doesn’t churn users in a dramatic moment; it erodes them.

The cleanest study here comes from a subscription business, not a shop. The Financial Times deliberately slowed its own site for groups of subscribers and watched what happened. A 1-second delay cut the number of articles people read by 4.9% over a week. A 3-second delay cut it 7.2%, and the gap kept widening over 28 days. Nobody rage-quit. They just read less, and a subscriber who reads less is a subscriber who doesn’t renew. That is what performance churn looks like: invisible in week one, expensive in month twelve.

4. Search ranks the fast: Core Web Vitals are free traffic

Google’s Core Web Vitals are a ranking signal, and they are concrete numbers, not a vibe. Google grades every page on three thresholds:

LCP (Largest Contentful Paint) under 2.5s: how fast the main content paints.
INP (Interaction to Next Paint) under 200ms: how fast the page reacts when someone clicks or types.
CLS (Cumulative Layout Shift) under 0.1: how much the layout jumps around while loading.

Miss them and you slide down the results while a competitor’s page gets the click. And the data comes from real users in Chrome (the CrUX dataset), so you can’t pass the test on your laptop and fail it in the field: what your actual visitors experience is what Google scores.

Note that the conversion wins in #2 (Rakuten, redBus, Vodafone) came from optimizing exactly these three metrics. That is the double payout: slow pages attract fewer visitors, and the visitors who do arrive convert worse. For any business that depends on organic discovery, page speed is an SEO line item, not just a UX one.

5. Headroom defers your next migration: hidden capex

An efficient app absorbs growth. Double the users or eat a traffic spike on the same infrastructure, because you had headroom. A slow app hits a wall and forces an expensive, risky re-platform or emergency scale-out, at the worst possible time: right when you’re growing.

Performance work is deferred capex. Every month you run lean is a month you didn’t have to spend re-architecting under fire.

6. Slow software taxes your engineers: hidden opex

Slow systems generate timeouts, on-call pages, and firefighting. Engineers burn hours chasing performance incidents instead of shipping. The tax reaches past engineering, too: slow screens produce “is it down?” support tickets and calls, each one costing support time and a little customer trust, and the worst ones escalate right back to the same engineers. Worse, slow is usually a symptom: of tangled architecture, missing indexes, chatty services. The same rot makes every future change slower and riskier to ship.

Fast systems are clean systems, and clean systems are cheaper to change. The same untangling that makes an app fast (clear boundaries, fewer moving parts, queries you can reason about) is what makes it safe to ship often. On one project I worked with, the performance and architecture cleanup is what took releases from 2 per month to daily. Both wins came from fixing the same root cause.

”But those studies are all e-commerce”

Mostly, and a sharp CTO will say so. The Financial Times experiment is the exception, and it’s the one that maps to SaaS: a subscription business, measured on reading, not checkout. Still, if you run a subscription product (B2B or B2C), you don’t have a one-shot checkout funnel, so “100ms = 1% of sales” doesn’t map directly. Be honest about that. The studies are directional: they prove the mechanism (humans abandon slow software, fast software earns more per user). They are not a formula you plug your revenue into.

Here’s how the same mechanism shows up in a subscription model:

Renewals and retention, not checkout. A slow tool your customers use daily becomes the reason a B2B renewal “gets reviewed,” the reason a champion can’t sell the upsell internally, or the reason a B2C subscriber quietly cancels. Performance is a retention and expansion input, just on a months-long clock instead of a 5-minute one.
Gross margin, not conversion rate. In SaaS, infra cost is cost of goods sold. Cutting it (angle #1) lifts gross margin directly: the number investors actually price.
Sales cycle / signup. “It’s fast” closes B2B technical evaluation and security review faster than any feature checkbox, and it lifts B2C trial and signup completion the same way the e-commerce studies show. Slow reads as unreliable, no matter what kind of software you sell.

How to tell if you’re leaving money on the table

You probably have a performance problem worth money if any of these are true:

Your cloud bill grew faster than your user count.
“Just bump the instance size” is a recurring move, not a rare one.
p95/p99 latency is multiples of your median (a few slow requests are poisoning the experience).
You don’t know your p95, because nobody’s measuring it.

The fix almost never starts with rewriting. It starts with measuring: percentiles under real load, then a slow request sliced across the stack to see where the time actually goes. Is it the frontend (JS bloat, heavy images, a missing CDN)? The backend? The database? A third-party API you sit waiting on? The split tells you where the lowest-hanging fruit is. The biggest wins sit in a handful of unindexed queries and over-provisioned instances: findable in an afternoon, worth a real line on the bill every month after.

Summary

Performance is one of the rare levers that moves cost and revenue together: less infra spend, more conversions, better retention, higher search rank, deferred migration, lower engineering tax. The public numbers are e-commerce, but for B2B SaaS the same physics lands on renewals and gross margin. Either way, slow software is a recurring bill you’re paying in money you can’t see.

Sources

Is your cloud bill growing faster than your user count? Book a free 30-minute call and I’ll look at where speed (or just better tuning) would move your bill and your latency. Or grab the free AWS cost checklist to find quick wins on your own.