The 2%: Why Edge Cases Decide Whether People Trust Your Product

Every demo runs the happy path. You type the obvious input, the obvious thing happens, everyone nods. The happy path is real — but it is not where products are won or lost. After thirteen-plus years of shipping software, the clearest pattern I know is this: people decide whether to trust a product in the 2% of cases the demo never shows them.

The 2% is the flaky network. The duplicate tap. The expired token. The receipt photographed at a weird angle. The user who does the steps out of order because your mental model wasn't theirs. None of it is glamorous, none of it demos well, and all of it is where trust actually lives.

Why the happy path lies

When I built real-time multiplayer systems, the hard part was never the smooth session. It was keeping a lot of clients honest over connections that drop, stall, and reorder packets — authoritative server, lag compensation, reconciliation. You can write the happy path in an afternoon. The 2% is the part that takes the other three weeks, and it's the only part the user feels when things go sideways.

The lie of the happy path is that it makes a product look finished when it's barely started. A demo that works once proves almost nothing. A product that fails gracefully the hundredth time something weird happens — that's the thing people quietly come to rely on.

The happy path is never the hard part. It's the 2% of edge cases that decide whether people trust you.

What this looks like in practice

On a consumer mobile product, the interesting work isn't the feature the demo shows. It's the guardrails around it: keeping AI-generated content grounded so it doesn't drift, building evals so quality holds across platforms, and making flows feel fast on a phone with two bars of signal. The happy path gets you the demo. The 2% gets you the App Store rating.

The inputs people fat-finger at 11pm. The state that's valid on iOS and crashes on Android. The edge case that only triggers after 30 days of use. Get those wrong and the damage is worse than a missing feature — it's a confidently broken experience, which is exactly the thing a product that has to earn daily use can't afford.

The engineering team version

Running a 12-engineer mobile team sharpens all of this, because the distance between an engineering decision and a user's experience is short. If we miss the 2%, it doesn't surface in review — the user just uninstalls. So I've learned to budget disproportionate time there on purpose, and to treat QA on edge cases as design work, not cleanup.

Concretely, that means three habits. Write the failure case before the success case, so the product degrades into something honest instead of something broken. Instrument the boring paths, because the bug you can't see is the one that costs you a customer. And treat every dependency — including AI — like something you have to operate at 3am, because eventually you will.

The happy path gets you a demo. The 2% gets you a product people keep using. If you're building software that has to actually run — applied AI, real workflows, the unglamorous middle — that's where I'd spend the next sprint.

Arun Jalota is a Technical Director in Toronto leading a 12-engineer mobile team and driving AI tooling adoption. Reach him at arun@arunjalota.com · LinkedIn · GitHub.