x
The short answer: stop starting. Go and count the AI things you began this summer and never finished, put every one of them in exactly one of three columns — finish, park, kill — and allow only one item to sit in "finish" at a time. The pile isn't a discipline failure. It's the predictable result of starting getting cheap while finishing stayed expensive. Clearing it is a two-hour job, and it is almost certainly worth more than anything new you could start this week.
That's the whole decode. The rest is why it happens and how to do it without leaving anything running that shouldn't be.
Because the economics of starting changed and nothing else did.
Two years ago, building a workflow that read your inbox and drafted replies meant a developer, a specification and a fortnight. The cost of starting was high enough to make you serious: you'd think about whether it was worth it, and once you'd committed the fortnight you finished, because abandoning it was visibly expensive.
Now it costs an afternoon and a prompt. Which is a genuine gain — that's real capability arriving in ordinary hands, and this newsletter is not about to complain that things got easier. But there's an arithmetic consequence nobody warns you about. When starting costs an afternoon, you start nine things. And the part that didn't get cheaper is the last ten per cent: the edge cases, the error handling, deciding where the output actually lands, and telling someone the thing exists.
So the pile is not evidence that you're disorganised. It's evidence that you responded rationally to a change in prices. It's just that the response leaves you holding nine things at seventy per cent, which returns nothing, rather than one thing at a hundred per cent, which returns something.
August made this worse in a specific way. There were eleven-plus major model releases in about twenty days this month. The old strategy — try the new thing, compare it, decide — quietly stopped being possible, because the next wave now lands before you've finished evaluating the last one. If your instinct is that you're falling behind, the honest read is that everybody is, permanently, and that the only thing still under your control is whether any of it gets finished.
It's a real pattern, and it's worth being precise about whose data says so.
Gartner found that over half of generative-AI projects were abandoned after proof of concept by the end of 2025 — attributing it to poor data quality, insufficient risk controls, rising costs and unclear business value. Their own 2024 prediction had been thirty per cent; the outturn came in higher. They separately expect over forty per cent of agentic-AI projects to be cancelled by the end of 2027. MIT's Project NANDA study found 95% of enterprise generative-AI pilots delivered no measurable return, and — the more interesting finding — that internally built systems succeeded roughly a third as often as bought ones, because organisations consistently underestimated the engineering needed to carry their own pilot the last mile.
Here is the caveat, and it matters more than the numbers. Every one of those studies is measuring enterprises — organisations with procurement processes, steering committees and pilot budgets. A one-person business is not a small enterprise; it's a different animal with different failure modes. None of that research was collected about you, and anyone quoting it at you as though it were is doing something sloppy.
What travels is the shape, not the statistic: the model was never the hard part, and the last mile is where things die. That pattern holds at every scale, because it's about human attention rather than organisational structure. The finishing work is boring, unglamorous and invisible, and it is the only part that produces value.
Hour one: see the pile. You cannot decide about things you cannot see, and almost nobody can list their half-built projects from memory. Open your automations tool and look at every draft, not just the live ones. Open the pinned chats. Open the folder you optimistically named "AI". For each item write four things: what it was meant to do, how done it honestly is, whether it is running right now, and what it can reach.
That third and fourth column are the ones people skip, and they're the ones that matter — which brings us to the part of this that isn't productivity advice.
Hour two: three columns. Finish — it would save you time this month and you know what's left. Park — good idea, wrong quarter; write down why you stopped and give it a date to revisit, because a parked thing with a reason is retrievable and a parked thing without one is just forgotten. Kill — it solved a problem you no longer have.
The rule that makes it work is the uncomfortable one: only one item may sit in Finish. Everything else parks or dies. A second Finish is exactly how the pile started.
And killing is allowed. That's the permission most people need, because abandoning something you built feels like admitting waste. It isn't. The waste already happened; the only question left is whether you keep paying attention rent on it.
Here's what turns a tidy-up into something more serious. Unfinished does not mean inactive.
That workflow you abandoned in June may still hold access to your files. It may still be sending things. What's near-certain is that nobody is reading its output, because you stopped looking in June. So you have an automated process, with live permissions, producing unreviewed work, that no one owns. That is precisely the shape of thing the last two weeks of this newsletter have been about — and it got there by neglect rather than by decision, which is worse, not better.
So switching something off is finishing it. Decommissioning is work, not the absence of work; an off switch is a deliverable. The order matters: pause it rather than deleting it, wait a week and see what breaks (nothing breaking is your green light; something breaking has just told you it was load-bearing). Then revoke its access everywhere, not only in the tool you built it in. Export anything you'd miss. Cancel whatever it was quietly paying for. Finally write one line recording what it did and why it stopped — future you will ask, probably at the worst possible moment, and that line is the entire handover.
This is what governed performance looks like at the smallest possible scale: not a policy document, but knowing what's running, what it can touch, and who reads what it produces.
Book the last hour before you start building anything else. Diary it. Define done in one sentence, and use three tests: it runs without you present, someone would notice if it stopped, and you could hand it over in five minutes.
Then finish one thing. Not the most exciting one — the closest to done.
For the tools worth finishing with — free, vetted, 5-min read: 10 AI Tools That Save 10 Hours a Week.
This week's decodes
Related Decodes
🔒 Founding members get the Finish-It Inventory Sheet — the four-column pile audit and the decommission checklist as a single printable page.
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: AI collapsed the cost of starting a project but not the cost of finishing one, so most solo operators are now carrying a pile of things at roughly 70% — which returns nothing. Gartner found over half of generative-AI projects were abandoned after proof of concept by end-2025 (against its own 30% prediction) and expects over 40% of agentic-AI projects to be cancelled by end-2027; MIT's Project NANDA found 95% of enterprise pilots delivered no measurable return, with internal builds succeeding a third as often as bought ones. Those measure enterprises, not one-person businesses, but the shape travels: the last mile is where things die. The fix is a two-hour clear-out — inventory every half-built thing on one page, then sort into finish, park or kill with only one item allowed in finish. Crucially, unfinished doesn't mean inactive: abandoned automations can still hold file access, still send things, and have nobody reading their output, so switching one off properly is finishing it, not failing at it.
