The small decisions that make software feel good.

Nobody has ever told me they loved an app because of its architecture. They tell me it feels fast, or that it never loses their work, or that the button is where their thumb expected it to be. Those are all small decisions, and almost none of them show up in a roadmap.

The first one I always look at is the gap between a click and a response. If something is going to take longer than about a hundred milliseconds, the interface owes the person a sign that it heard them. A pressed state, a spinner that waits a beat before appearing, a row that greys out while it saves. None of it is hard. All of it gets skipped when a deadline is close.

The second is what happens when things go wrong. A form that keeps everything you typed after a failed submit is worth more than a beautiful error illustration. An undo that actually undoes is worth more than a confirmation dialog that everyone clicks through without reading.

Then there is copy. I rewrite button labels more than any other line of code I touch. "Submit" becomes "Save draft", "OK" becomes "Delete 3 entries". The verb tells people what will happen, and the number tells them how much.

Keyboard support is the one I used to treat as optional, and I was wrong. The people who use your tool every day will learn the shortcuts within a week, and from then on every missing one is a small, repeated papercut. Focus rings that are visible, Escape that closes things, Enter that does the obvious thing.

What ties all of this together is a feedback loop. I keep a running note while I use my own software, and every time something makes me hesitate, I write it down. Most entries take ten minutes to fix. The list never empties, but the product gets a little calmer every week.

Polish is not a phase at the end. It is a habit of paying attention, and it compounds.