Most teams file a broken button under "bugs". It goes on the board, gets a priority, and waits its turn behind everything else.
That is the wrong mental model. A broken button on an important page is not a bug in any meaningful sense. It is a leak in your revenue, and it runs every hour it stays open, whether anyone is looking or not.
So let's stop talking about it in the abstract and put an actual number on it.
A very ordinary SaaS
Nothing about this business is unusual. Thousands of products look roughly like it:
- 30,000 visits a month to the signup page
- 40% of those visits on phones, and about half of the phone visits on iPhones
- 4% of visitors start a free trial
- 15% of trials become paying customers
- each customer pays $79 a month
On a Thursday afternoon, someone ships a small change to the header. On iPhones, a sticky banner now sits directly on top of the "Start free trial" button. The button is still there. It just cannot be tapped.
Nobody on the team uses an iPhone at that size. Nothing raises an error. Every monitor stays green.
The bill for one month
- 6,000signup page visits on iPhones
- 240trials that should have started
- 36customers who should have paid
- $2,844a month in revenue that never arrives
Example figures: 30,000 visits a month, 20% on iPhones, 4% start a trial, 15% of trials pay, $79 a month each.
Thirty-six customers at $79 a month is $2,844 of monthly revenue. Over a year, those customers would have been worth $34,128. All of it lost to one button, on one kind of phone, for one month.
And a month is generous. Plenty of these faults sit there for a quarter before anyone spots them.
Time is the multiplier
The shape of that chart is the whole argument. The fix takes the same ten minutes whenever you find it. The only variable that changes the cost is how long it takes you to notice. Found the same evening, the damage is a rounding error. Found at the end of the quarter, it is a six-figure hole in the plan.
It isn't just SaaS
The same arithmetic applies to any business whose website does the selling. Two more worked examples:
| Online shop | Booking site | |
|---|---|---|
| Monthly visits to the key page | 50,000 product pages | 8,000 booking pages |
| Share on the broken device | 15% on tablets | 60% on phones |
| Visits that hit the fault | 7,500 | 4,800 |
| Conversion on that page | 8% add to cart, 40% of carts order | 6% book |
| Lost each month | 240 orders | 288 bookings |
| Value of each | $65 average order | $90 per booking |
| Revenue lost in one month | $15,600 | $25,920 |
Different industries, different devices, the same conclusion: one broken control on one important page, left alone for a month, costs more than most teams spend on their entire monitoring stack in a year.
The costs that never show up in a spreadsheet
The numbers above are only the part you can count. Several others hurt just as much:
Your ad spend keeps running. Your campaigns don't know the button is broken. Every click you buy lands on it, and you pay for every one.
Your team optimises the wrong thing. Signups drop, so marketing reworks the campaign, someone rewrites the headline, and the pricing page gets a redesign. Weeks of skilled work, aimed at the wrong cause, while the button sits there broken.
Your support costs rise. The few customers who do get in touch send vague, frustrated messages. Each one takes time to investigate, and most end in "could not reproduce".
Your brand takes the hit quietly. A visitor who couldn't sign up doesn't think "their layout has a bug". They think "this product feels janky". That impression lasts far longer than the fault.
Why it's always the most valuable pages
There is a cruel irony in where these faults appear. Signup, checkout, pricing and booking pages change more often than any others, because they are the pages everyone is trying to optimise. More experiments, more banners, more widgets, more releases.
Every change is a new chance for something to land on top of something else. So the pages most likely to break are precisely the pages where breaking costs the most.
Run it on your own numbers
You need four figures, and your analytics already has every one of them:
- Monthly visits to your most important page
- The share of those visits on one device type, such as iPhones or tablets
- Your conversion rate on that page
- What a customer is worth to you over a year
Multiply them together:
visits × device share × conversion × yearly customer value = what a month of one broken button costs you
Running a shop? Use your average order value. Taking bookings? Use what a booking is worth. Whatever the inputs, the answer tends to come out large enough that nobody would ever leave that button broken on purpose.
That is the catch. Nobody does it on purpose. They simply don't know.
The metric that decides the bill
Engineering teams have measured "time to detect" for server outages for years. It is one of the most important numbers in operations, and the best teams obsess over driving it down.
Almost nobody measures the same thing for the interface. Yet from the arithmetic above, it is the single number that decides how much a broken button costs: not the severity, not the fix, but the time between the moment it breaks and the moment someone knows.
For most teams today, that number is measured in weeks, and it ends when a customer finally complains or a metric dips far enough to start a meeting. The best teams are bringing it down to minutes.
How Spectra makes the month disappear
Spectra is interface intelligence for the web, and it exists to collapse time to notice from weeks to minutes.
It watches every real visit to your site, on every phone, tablet and laptop, and knows the moment a button that matters stops working for real customers. You hear about it within minutes, not weeks, with the visit attached so you can watch the tap, the nothing, and the exit for yourself. It tells you which release caused it, so the fix takes minutes and never comes back.
Think about what that is worth. If Spectra catches a single broken signup button in a year, it has paid for itself many times over. Most teams have more than one.
Run the maths on your own numbers. Then ask yourself how long your team would take to notice without it.