The last 10%: what users feel but never mention

No user has ever written a review that says the keyboard avoided the input correctly. Nobody praises an app for surviving a flaky connection, or for a list that keeps its scroll position after a refresh. This work is invisible by definition. When it is done, nothing happens.

But users feel it. They cannot name it, and they do not have to. It shows up as trust. The app that never loses their draft is the app they open without thinking.

What the last 10% actually is

It is not polish in the decorative sense. It is the behavior of the app at its edges:

• The keyboard. Every input reachable, nothing jumping, dismissal that feels physical.
• Interruptions. A phone call mid-checkout, a backgrounded upload, a push notification during onboarding. The app comes back exactly where it was.
• The network. Slow is worse than offline. Show what you have, queue what you cannot send, never block the whole screen for one request.
• Touch. Targets that fit thumbs. Gestures that can be cancelled halfway. Animations that can be interrupted by the next tap instead of playing out while the user waits.
• Empty, loading, and error states designed with the same care as the happy path, because a first-time user meets all three in the first minute.

Why it gets cut

The last 10% is the first thing dropped under deadline, because nothing visibly breaks without it. The demo works. The screenshots look identical. The difference only appears at scale: in retention curves, in support tickets that never get filed, in reviews that say “it just feels solid” without saying why.

How I budget for it

I stopped treating it as a final phase. There is no week at the end where the team polishes. That week does not survive contact with a roadmap.

Instead, edge behavior is part of the definition of done for every feature. A screen is not finished when it renders. It is finished when it renders on a slow connection, mid-interruption, with the keyboard up, in both themes, and recovers from every failure its API can produce.

That sounds expensive. It is cheaper than the alternative, which is shipping the visible 90% and spending the next year discovering the missing tenth one bug report at a time.

The invisible work is the product. Users feel it, and they never mention it. That is how you know it worked.