When teams decide whether to invest in testing, they usually compare it against the cost of fixing bugs later — and they estimate that cost as engineering hours. A day to diagnose, half a day to fix, a few hours to ship. Call it two days.
That number is wrong by a wide margin, because engineering time is the smallest component of what a production bug actually costs.
What a production bug actually costs
The interrupt
A production bug does not arrive politely at sprint planning. It arrives mid-morning, and it displaces whatever was planned.
The direct cost is the fix. The larger cost is the context switch: work in progress gets abandoned half-finished, planned work slips, and the team spends the rest of the day re-establishing where they were. For a small team, one production incident routinely costs more than the day of feature work it interrupted.
The support load
Every affected user who cares enough to contact you generates a ticket. Each ticket needs a reply, and often a follow-up when the fix ships.
For a small team that support load lands on the same people who are fixing the bug — which is why production incidents feel so much more expensive than the fix suggests. You are paying for the fix and the communication, from the same pool of hours.
The store review cycle
This is the one that turns a small bug into an expensive one, and it is specific to mobile.
You cannot hot-fix a native app. Once a broken build is live, the sequence is: notice, diagnose, fix, build, submit, wait for review, roll out — and then wait again while users actually update. Review times vary and are not under your control.
The consequence: a web bug can be live for twenty minutes. The same bug in a mobile app is live for days, and continues affecting users who have not yet updated for considerably longer. This asymmetry is the single strongest argument for testing mobile releases harder than web ones.
The reviews
This is where the cost stops being linear.
App store ratings are sticky and slow to recover. A cluster of one-star reviews during a bad release drags your average down, and the average is what every future potential user sees next to your name. Worse, the reviews themselves persist — "crashed on login, don't bother" sits near the top of your listing long after the bug is fixed, because unhelpful negative reviews accumulate votes.
Ratings also feed store ranking. A drop in rating reduces discovery, which reduces installs, which is a cost you keep paying long after the bug is closed.
The users who just leave
The largest cost, and the only one that never shows up in any dashboard you look at.
Most users who hit a serious bug do not file a report, do not leave a review, and do not contact support. They close the app and do not come back. For a user still in their first session, the tolerance is close to zero — they have no investment in your product and an app store full of alternatives.
You cannot see this in your metrics as a bug. You see it as a dip in activation or retention that gets attributed to something else entirely.
The trust cost
Reliability compounds in both directions. Users who have never seen your app fail extend it the benefit of the doubt when something looks odd. Users who have been burned once interpret every subsequent slow load as the app breaking again.
This is the cost that makes regressions worse than new-feature bugs: the user already knew that feature worked, so the failure reads as the product getting worse.
The asymmetry that matters
Now compare the two sides.
Finding a bug before release costs: some testing time, a report, and a fix in the normal flow of work. No interrupt, no support load, no store review cycle, no public reviews, no lost users.
Finding it after release costs: all of the above, several times over, and some of it permanently.
The ratio is not two or three times. For a bug that reaches the store and generates reviews, it is not really a ratio at all — the review damage and the users you never hear from are not recoverable at any price.
This is why the traditional cost-of-defect argument understates the case for mobile. It was formulated for software you could patch. When your release cycle includes an external review queue you do not control, the cost of shipping the bug rises sharply while the cost of catching it stays flat.
Where to spend, given limited time
You cannot test everything. Spend where a failure is most expensive:
The first-run experience. New users have zero tolerance and produce your harshest reviews. A bug in onboarding costs you the user permanently, and often costs you a public review as well.
Anything touching money. Payment bugs generate support tickets, refunds, chargebacks, and the angriest reviews you will ever receive. They also erode trust in a way feature bugs do not.
Anything that could crash on launch. A launch crash is the maximum-damage bug: total, immediate, affects everyone, and produces one-star reviews within hours.
Whatever you just changed, plus everything that touches it. Regressions in features users already relied on do disproportionate trust damage.
Data loss, above all. Users forgive a crash. They do not forgive losing their work.
The framing that actually helps
The question is not "can we afford to test this release?" It is "what would it cost if the thing we did not check turns out to be broken?"
For a cosmetic issue on a settings screen, very little — ship it. For the payment flow, or the first ten minutes a new user spends with your product, the answer is large enough that a testing pass is obviously cheaper than the alternative.
Most teams do not need more testing across the board. They need testing concentrated on the handful of flows where failure is expensive, done by people who did not build the thing and are therefore capable of using it wrong.
That is what Bugfed is for: vetted testers on real devices running the flows that matter, returning structured bug reports before your users write the review instead of after.