Build for the cheapest phone in the building

Most app teams develop on the best phone they own, test on a simulator, and discover the real performance of their product from a one-star review.

The gap is wider than you think

The device on a developer's desk has several times the processing power, several times the memory and a far better network position than the phone in a warehouse worker's pocket. An animation that is smooth on one is a stutter on the other. A screen that loads instantly on office wifi takes eleven seconds on a factory floor.

You cannot reason your way across that gap. You have to hold the other phone.

What we do

We buy the cheapest current handset that a real user might plausibly have, and it becomes the development device for the project — not the test device, the development device. Every day, on the bad phone.

It changes decisions upstream rather than catching them downstream:

• Heavy animation stops being proposed, because nobody wants to build something they watch stutter all day
• Image sizes get argued about in the design review instead of in a performance sprint
• Screens get simpler, because complexity is immediately, physically annoying
• Offline behaviour becomes a first-class feature rather than an edge case, because you experience the disconnection constantly

The side effect

An app built to be usable on a slow phone is fast on a good one. The reverse is not true.

Nobody has ever complained that an app was too responsive.

The one argument against it

Development is slower. Builds take longer to install, the debugger is less pleasant, and hot reload is not as quick.

That is real, and it is worth it. The time you lose is time you would otherwise spend later, in a worse mood, with users already unhappy.