etzee

Designing for the phone most people actually have

A mid-range Android on patchy data, not a laptop on fibre. That assumption decided more of this product than any feature did.

The Metzee team20 Oct 20263 min read

The device this was built for is a three-year-old Android phone on mobile data with two bars. Not as a worthy exception — as the default case, the one the product has to be good on rather than merely survive.

That assumption makes decisions for you, and most of them are subtractions.

It decides what a live show can be

A live auction on a weak connection is the hardest thing in the product, because video and a shared price have opposite requirements: video wants a big steady stream, the price wants tiny messages that arrive in order and now.

So the price is not in the video. It arrives separately, as its own small update, which is why the number on your screen can be right while the picture is a few seconds behind. On a good connection that separation is invisible; on a weak one it is the difference between a usable auction and a guess.

Two further consequences of the same assumption:

A burst of bids becomes one update. A host counting down while three people tap produces several bids in a moment, and sending each one separately would be several times the work for a phone that is already struggling. They are gathered — 400 ms of gathering — and delivered once.

Silence is not trusted. A connection that has died looks exactly like one where nothing is happening, so once it has gone quiet for 6 seconds the phone asks the server directly rather than believing the quiet. That one rule is the difference between a dropped connection you recover from and a frozen price you have to reload to escape.

It decides what a page may weigh

Photographs are the page. A listing is six photographs at most, and that limit is as much about the phone loading them as the seller uploading them.

Text instead of images of text, which the languages require anyway and a slow connection rewards.

Nothing that only works after a large download. A page that is blank until a bundle arrives is a page that is blank, on this phone, for long enough to leave.

It decides what the app asks of the device

Heat before power. On an older phone the limit is usually thermal rather than processing — the phone slows itself down to cool off, especially while streaming. Which means the fix for a struggling show is often closing other things and taking the case off, not buying a phone.

Storage, which fills. An app that hoards gets uninstalled by somebody who needs the space for photographs of their family.

What this assumption rules out

Interfaces that need precision — small targets, hover, anything needing a steady hand on a bus. Long forms that lose their contents when a connection drops mid-way. Anything where the first useful thing happens after several seconds of waiting.

Most of those would be fine on a laptop on fibre. None of them is fine as the default.

Why not just build for the good case

Because the people this marketplace is for are not on the good case, and a product that works beautifully on a fast phone and badly on a slow one has quietly chosen its customers. That is the same filter as an English-only product, wearing different clothes.

Questions people ask

Does the site need a fast connection?

No, and a show degrades rather than stopping — the picture gives way before the auction does.

Why does my video lag behind the host?

Because video travels and is rebuilt at your end. The clock extends by 10 seconds on a late bid precisely so that lag cannot cost you an item.

Is an older phone genuinely usable for selling?

Yes, including hosting a show. Heat is the thing to manage, not power.

More: using Metzee on an older Android phone, how fast does my internet need to be, what happens during a live show, why twelve languages is a constraint.

← All posts

There is a show on right now.

Nothing to install — it runs in this browser.

Find a showCreate an account