“Software is never finished,” people say, usually right before they ask for one more change. We have never found this to be true in a useful way. Of course a site can always be different. The question is not whether more is possible — more is always possible — but whether more is better, and at some point it stops being better and starts being fidgeting.
Finishing is a skill. It is harder than starting and rarer than polishing. Here is how we do it.
Done is a definition, not a feeling
The mistake is to wait until a site feels done. That feeling never reliably arrives, because the person closest to the work has seen every pixel a hundred times and can always find a flaw. If you ship on feeling, you either ship too early, anxious, or never ship at all.
So we define done in advance. Before we build, we write down what the site has to do and how we will know it does it. For a studio site that might be: the five rooms exist, every page states its argument in one sentence, the contact path works, the pages pass the performance and accessibility bar, and nothing is broken. That list is the definition. When the list is true, the site is done — regardless of how anyone feels at that moment.
The bar is a line, not a horizon
We hold a clear quality bar: the site has to be fast, accessible, indexable, and free of obvious defects. That bar is a line you cross, not a horizon you chase. A perfect score is a horizon. Crossing the line — every page measurably good, no broken links, no errors — is something you can actually reach and then stop.
We have watched teams burn a week chasing the last few points on a score that was already past the line. Those points cost real time and bought nothing the reader will ever notice. Cross the line, confirm you crossed it, and move on. The last increment of perfection is almost always the worst-priced work on the project.
Finishing means subtracting
Near the end of a project there is a strong pull to add: one more section, one more animation, one more clever touch. Resist it. The end of a project is for subtracting — removing the thing that was almost good, tightening the sentence that was almost clear, cutting the flourish you kept because it was hard to make.
A finished site is not the one with the most in it. It is the one where everything that remains is there on purpose. You reach that by taking away, not by piling on.
Ship, then leave it alone
When the definition is met and the bar is crossed, we ship. And then — this is the part people skip — we leave it alone. A finished site does not need weekly tinkering. It needs to exist, do its job, and be left to do it. The instinct to keep touching a live site is usually boredom dressed up as diligence.
There is a real kind of care that comes later: fixing what genuinely breaks, updating what genuinely changes. That is maintenance, and it is different from never having finished in the first place. Maintenance is tending a thing that is done. Fidgeting is refusing to let it be done.
The relief of done
The best argument for finishing is how it feels afterward. A finished site is off your desk. It is working without you. The energy you were spending on it is free for the next thing. That relief is not laziness — it is the whole point of building something. You build it so it will run, and then you let it run.
A website is done when it does its job, clears the bar, and contains nothing you are still arguing with. Write that down before you start. Then, when it is true, believe it.