Build for the phone people have, not the one on your desk

There is a version of your product that only exists on the developer's laptop. It is fast, the images are crisp, and every interaction feels immediate. Then it ships, and the numbers come back from people using a four-year-old Android phone on a connection that drops when they walk indoors.

We've shipped enough of these to know that the gap usually comes from the device you pictured while building, not the quality of the code.

The three things that actually hurt

Images nobody resized

A hero photo exported at 3000 pixels wide costs a user real money in data and several seconds of staring at nothing. Serve the size the screen will use, in a modern format, and stop shipping the desktop version to a 360-pixel phone.

JavaScript that has to run before anything appears

On a mid-range processor, parsing and executing a large bundle is not free the way it is on a laptop. Render the first screen on the server. Add interactivity after, deliberately, where it earns its cost.

Assuming the request will succeed

The most common failure we fix is a form that loses everything when the network blinks. Save locally as the user types, reconcile when the connection returns and show the current state of their data.

If your app has never been tested with the network throttled and the cache cleared, you do not yet know how it behaves for most of your users.

How we test

• A real mid-range Android handset, not a simulator.
• Network throttled to something like a busy 3G cell.
• Cold cache, because first impressions happen once.
• Airplane mode toggled mid-task, to see what breaks.
• A 360-pixel viewport as the default design width.

The techniques are straightforward. The important decision is who you're building for, made early enough to shape the work.