🎧 Listen to this article (5:15)
The last 10% is not always the hardest part of making something. It is often the part with the most friction. The interesting creative work may already be done, and what remains is testing, fixing edge cases, writing instructions and dealing with the small details that were easy to postpone.
Progress becomes less visible just as the work becomes less enjoyable. Moving from nothing to 50% feels like enormous progress, while moving from 92% to 93% barely feels like progress at all. The closer something gets to finished, the easier it becomes to convince yourself that it already is. That final stretch determines whether somebody else can actually use what you have made.
The core can be excellent while the product is unfinished
I recently installed an open-source text-to-speech system on my Mac. Once it was running, the voice quality was excellent. The difficult part was getting there.
I had to use Terminal, install dependencies and work out which steps to take, but the biggest barrier was trust. macOS displayed security warnings discouraging me from opening parts of the software. The warning itself was not necessarily something the creator could remove, but the documentation could have anticipated it, explained what it meant and told me what to do next.
I chose to investigate and continue. Many users would reasonably stop rather than override a security warning for unfamiliar software. A product can be brilliant inside the box, but that brilliance means little to someone who can’t open the box.
The last 10% for the creator is often the first 10% for the user
Physical packaging makes the problem easy to see. A product can arrive safely in bubble wrap inside a plain cardboard box, and that might be perfectly good packaging. Finished does not mean luxurious. What matters is whether someone can open it, understand what they received, and start using it without unnecessary difficulty.
Digital products have packaging too. Installation, onboarding, sensible defaults, navigation and documentation sit between what was built and the person trying to use it. To the creator, these may feel like finishing work. To the user, they are part of the product.
Unfinished work changes hands
Skipping the final work can look like a saving. You avoid another hour of removing a confusing step, writing clearer instructions, or testing what happens when somebody takes a route you didn’t expect.
If fixing one confusing step takes you an hour, you pay that cost once. Leave it there, and hundreds of users might each spend several minutes trying to understand it. Some will work it out. Others will leave.
Finishing costs the creator once. Leaving something unfinished can cost every user who encounters the same problem. The remaining work does not disappear. It changes hands.
AI gets us to 90% faster
AI can move an individual from an idea to a first version much faster. Writing, code, images, websites and prototypes can now take shape with far less manual work.
That speed does not remove the need for final judgement. AI can produce something that looks complete, but someone still has to use it, question it, check it and decide whether the gaps matter. As the cost of producing a plausible first version falls, finishing becomes a larger part of the job.
What about shipping early?
There is good reason not to polish a product forever. Ship early, build an MVP, learn from real users and improve what matters. Stopping too early and chasing perfection are opposite failures. One arrives incomplete. The other may never arrive.
But limited and unfinished are not the same thing.
An MVP can have three features instead of ten and still make those three features work properly. A simple website can have five pages instead of fifty and still have working forms, understandable navigation and a good mobile experience. Reducing scope is a design decision. Making the user compensate for work you chose not to finish is something else.
Shipping early should help you discover what to build next. It should not require the user to finish what you have already built.
Finished is not polished
A rough-looking product can be finished. A beautiful product can be unfinished. Polish is about refinement. Completion is about whether the thing successfully does what it promises for the person it was made for.
The problem is that familiarity makes creators poor judges of their own unfinished work. You already know what a button does, what an instruction means and what happens next. The user does not, which is why the feeling that something is finished is not a reliable test.
A better finishing check is practical: Does it work? Can the intended user understand what to do? Can they recover when something goes wrong? Am I leaving them to solve a problem that I should have solved?
If those answers are good enough for the purpose, stop.
The aim is not perfection. It is to reach the point where your work can leave your hands without asking the next person to finish it for you.
