Book the last hour before you start building, and define done in one sentence. The final ten per cent of any automation is the boring residue — edge cases, error handling, where the output actually lands, and telling someone it exists — and it costs more attention than the first ninety per cent because none of it is fun and none of it produces a visible win. It is also the only part that converts effort into value. A workflow that almost runs saves you nothing; there is no partial credit.
Four things, and they're the same four almost every time.
Edge cases. The invoice with no PO number. The email in a language you didn't expect. The empty result. Building for the happy path takes an afternoon; the unhappy paths are where the remaining hours live, and where an unattended automation earns or loses your trust.
Error handling. What happens when it fails? Silence is the default and the worst option, because a silently failing automation is indistinguishable from a working one until something downstream goes wrong. "Email me if this errors" is one line of configuration and it is the difference between a tool and a liability.
Where the output lands. Astonishingly often, this is the unfinished part. The workflow runs, produces something correct, and deposits it somewhere nobody looks. Output with no destination is the most common form of ninety-per-cent-done, and the easiest to fix in ten minutes.
Telling someone it exists. If it's a client-facing or team-facing thing, it isn't finished until the humans know. An automation nobody knows about gets worked around, and then you're paying for two processes.
Because none of it is the interesting bit, and because it's invisible.
Building the core of something is legible progress — you can see it work, you can show someone. Handling the empty-result case produces nothing you can demonstrate. The reward structure is upside down: the work that makes the thing real is the work that feels like it produced least.
This isn't a solo-operator failing. Gartner found over half of generative-AI projects were abandoned after proof of concept by the end of 2025, against its own earlier prediction of thirty per cent, citing unclear business value and weak risk controls among the causes. MIT's Project NANDA found 95% of enterprise pilots delivered no measurable return — and specifically that internal builds succeeded roughly a third as often as bought solutions, because organisations underestimated the engineering required to carry a pilot the last mile.
Those numbers describe enterprises, not one-person businesses, and they were not collected about you. They're cited here as evidence of a pattern rather than a statistic about your situation. But note what the pattern says: organisations with budgets, teams and governance committees fail at exactly the same step you do. The last mile is not a resourcing problem. It's an attention problem, and attention doesn't scale with headcount.

Three moves, all small.
Diary it before you start. Not "I'll finish it later" — an actual hour in the calendar, booked at the same time you start building. The last hour never happens spontaneously, because by the time you reach it the interesting part is over and something newer is available.
Define done in one sentence, in advance. Write it before you build. "Done means it runs every Monday without me, emails me if it fails, and files the output in the client folder." A sentence you wrote on day one is a specification. A judgement you make on day nine is a negotiation with yourself, and you will lose it.
Test against three questions. Does it run without you present? Would someone notice if it stopped? Could you hand it over in five minutes? Three yeses is done. Anything else is still building, whatever the percentage in your head says.
The reason this pays: finished things compound and started things decay. An unfinished automation gets less likely to be finished every week, as you forget how it works and the platform changes underneath it. A finished one keeps working without further attention. That last hour is the entire difference, and it is the cheapest hour in the project.
Related Decodes
For the weekend plan that finishes one of them — free, vetted, 5-min read: The Weekend Automation Plan.
AI the Brief (@aithebrief) — AI advice you can act on and trust, for time-starved founders.
Gartner and MIT figures describe enterprises, not one-person businesses; they are cited as evidence of a pattern, not as statistics about you.
TL;DR: The last ten per cent of an automation costs more attention than the first ninety, and it contains four things every time: edge cases, error handling, where the output actually lands, and telling the humans it exists. It's consistently the failure point because none of it is demonstrable — the work that makes something real is the work that feels least productive. Gartner found over half of generative-AI projects abandoned after proof of concept by end-2025 against its own 30% forecast, and MIT's Project NANDA found 95% of enterprise pilots delivered no measurable return, with internal builds succeeding a third as often as bought ones; that's enterprise data rather than solo data, but it shows organisations with budgets and committees failing at the identical step, so the last mile is an attention problem, not a resourcing one. Fix it by diarising the final hour before you start, writing the definition of done in one sentence in advance, and testing with three questions: does it run without you, would anyone notice if it stopped, could you hand it over in five minutes.
