The first error message is where your product actually begins

Every early product demos beautifully. The network is fine, the data was prepared in advance, every field is filled in the standard format. Then week one arrives: a user reaches step three, taps submit, and gets “Operation failed, please try again” — no explanation, no next action, and no way to tell whether anything actually went through.

A demo follows the one path that works. Users take all the others. What your product really is gets defined in the few seconds after something breaks.

A ten-link chain leaves you with 60%

“Mostly it works” is not how the math works. A ten-step flow at 95% success per step has an end-to-end success rate of 0.95 to the tenth power — about 60%. At twelve steps it drops to roughly 54%. One user in two has a failed first experience, and it is a failure your demo never showed you.

And it never reappears on demand. It shows up in a subway tunnel, or right after someone has spent eight minutes filling out a form, or the moment a third-party API starts rate-limiting. Those scenarios are hard to reproduce on a laptop, and they are the user's everyday reality.

The three failure screens we see most

• Screens passing as empty states. A blank list tells nobody whether there is no data, loading failed, or permissions are missing. An empty state should answer two things: why it is empty and what to tap next.
• Server logs pasted into the UI. “Request timeout 500” helps an engineer; for a user it is noise. Jakob Nielsen's classic usability heuristics say it directly: error messages should use plain language, state precisely what went wrong, and suggest a constructive way forward.
• Double submissions while the network hangs. Tapping a button that does nothing makes people tap it three more times. Without idempotency keys and retries with backoff and jitter, those taps become three orders, three emails, three charges. Public cloud guidance says the same thing: retry with backoff and jitter, or the retries make the outage worse.

Make a failure inventory part of the spec

Reliable teams are not teams that never make mistakes; they are teams that listed the mistakes in advance. Write failure points into the requirements: what happens when the third-party API is down, how an interrupted upload resumes, which side wins a data conflict, who owns a failed refund. The list usually takes a day to write and saves two weeks of firefighting.

• Give every failure three sentences. What happened, what to do now, who to contact. Not “upload failed,” but “the file is larger than 50MB — compress it and retry; if it still fails, send the screenshot to the on-duty contact.”
• Make retry actually retry. Add idempotency keys so repeat taps apply once. Give users a real retry button instead of forcing a page refresh that destroys eight minutes of typing.
• Walk the failure path before every launch. Kill the third-party API, throttle to 3G, mistype one digit of a card number, and watch whether the product still explains itself politely. Two hours of this usually surfaces more than a week of happy-path testing.

At 51kaifa.app, every early-product spec keeps a standing section called “failures and boundaries”: each timeout, each failed third-party call and each empty data case gets one line the user can read and one button they can press. The items look trivial. They are exactly why the first session goes smoothly, and why there is a second one.