The Site Was Perfect on My Phone. On a Three-Year-Old One, It Looked Broken.

I once opened something I’d built on an old phone — a tired, three-year-old handset on a weak connection, the kind I’d never normally test on. The smooth, animated, rather pretty thing I was proud of stuttered. It lagged on every tap, the animations dropped frames, and a page I knew was fine felt, unmistakably, broken. For a second I was annoyed at the phone. Then it landed: this isn’t my spare phone, this is my customer’s main one. On the device in their pocket, my polished work looked like a bug.

And here’s the cruel part — I would never have known. On my own phone, new and fast and well-connected, everything was perfect. That gap, between the device you build on and the device your customer actually holds, is one of the most expensive blind spots in any digital product. The person on the struggling phone doesn’t think “nice site, shame about my hardware.” They think “this is broken,” and they leave, and you never find out why.

TL;DR

• “Works on my machine” is a trap. Your device isn’t your customer’s.
• A heavy, fancy experience can feel broken on a slower phone.
• The fix is graceful degradation: detect weaker devices, give them a lighter version.
• Everyone gets something smooth. Nobody gets something broken.
• This applies to any product, not just websites.

The blind spot is built into your own hardware

Developers and designers tend to have good phones, big screens, and fast connections, so they build and test in ideal conditions, everything feels great, and they ship. Meanwhile a large share of real visitors are on older phones, smaller screens, and weaker signal. The exact experience that delights you can frustrate them, and the animations that feel slick to you drop frames and stutter for them. The trap is that you literally cannot see the problem, because your hardware hides it. “Works on my machine” is one of the oldest and most expensive lies in technology, and it’s usually told honestly.

What “feeling slow” quietly costs you

People decide whether something feels good or broken in the first couple of seconds, and they’re harsh about it. A stuttering page reads as low quality, a laggy interaction reads as untrustworthy, and they rarely blame their phone — they blame you. They leave, often without a single complaint that would tell you why. That’s the dangerous part: this failure is silent. The customers it costs you don’t write in to explain. They just quietly never come back, and your analytics show a bounce you can’t explain. You’re losing people to an experience you’ve never personally seen.

The fix: meet the device where it is

The answer isn’t “make everything plain so it’s fast for everyone,” because that punishes your visitors with good phones for no reason. The answer is graceful degradation: give capable devices the rich experience, and automatically give weaker ones a lighter version that runs smoothly. The site quietly senses what the device can handle. Strong phone, fast connection? Full experience, all the polish. Older phone struggling to keep up? It steps down to a lighter version (fewer heavy effects, less to load) that feels fast on that hardware. The visitor doesn’t choose this and barely notices it. They just get something that works, tuned to what their device can actually do.

Everyone gets something smooth, and nobody gets something broken.

This is a market decision wearing a tech costume

It’s tempting to file this under “engineering detail,” but it isn’t. It’s about who you’re willing to lose. Every visitor on a modest phone is a real potential customer, and in many markets that’s most of them. If your product only feels good on premium hardware, you’ve quietly decided to serve only people with premium hardware, without ever deciding it on purpose. That’s a market-size choice disguised as a tech tradeoff. So the question for anyone running a product: who are we accidentally excluding because we only tested on the nice devices? Often the answer is a big chunk of the exact audience you’re trying to reach.

What this means beyond websites

The principle generalises to any product. Don’t assume your users have the best conditions. Some have old hardware, slow connections, small screens, less technical comfort. A product that only shines in ideal conditions quietly fails most of the people you hoped to serve.

Build for the range, not the peak. Make sure the baseline experience, the one on the weakest device you care to support, is genuinely good and not an afterthought. The peak experience is nice. The baseline is what determines your reach.

What I’d tell someone shipping a product

Test on a bad phone. A real one, old and slow, on a weak connection. It’s uncomfortable, and it’ll humble whatever you built. That discomfort is the single most useful hour you can spend. The gap between your device and your customer’s is where your silent losses live.

“Works on my machine” feels like success. It’s actually the most reliable way to ship something that fails the people you’ll never hear from. Build for the phone in your customer’s pocket, not the one in yours.

So pick up the oldest, slowest phone you can find and open your own product on it. Would you stick around, or would you assume it’s broken and leave?