Unfinished does not mean inactive, and that is the whole argument. The workflow you abandoned in June may still hold access to your files, may still be sending things, and is certainly producing output nobody reads — because you stopped looking in June. That is an automated process with live permissions and no owner. It is not a head start on next quarter. It is the same category of thing this newsletter spent the last two weeks describing, arrived at by neglect rather than by decision, which makes it worse rather than better.

What's actually risky about something that never got finished?

Three things, none of them dramatic, which is exactly why they persist.

Access you forgot you granted. To build the thing, you connected it to your email, your storage, maybe your accounting or your calendar. That grant is still live. It sits in a connected-apps list you haven't opened since. Nothing has gone wrong, and nothing needs to have gone wrong for this to be worth closing — the point of least privilege is that you don't rely on nothing going wrong.

Output going out unchecked. If any part of it still sends, posts or files, it is speaking on your behalf without review. The half-built state is the dangerous one precisely because you're not watching: a finished automation has someone reading its output, and an abandoned one has nobody, by definition.

Cost you stopped tracking. A tier you upgraded to for one workflow. A per-run charge on something still triggering. Small, recurring and invisible, because you stopped associating the line item with the project.

None of these is a disaster. All of them are the shape of the thing that becomes a disaster later, and all of them are ten-minute fixes today.

Why does "I'll come back to it" make it worse?

Because it converts a decision into a drift, and drift has no owner.

A parked project with a written reason and a date is a decision — someone chose that, and someone will revisit it. A project you intend to return to is a belief, and beliefs don't revoke credentials. The gap between those two things is the entire governance content of this week.

There's a second effect, quieter. Every week an unfinished thing sits, it gets less likely to be finished. You forget how it works. The platform updates underneath it. The problem it solved shifts slightly. So the "head start" depreciates fast — often faster than the effort it would take to rebuild it properly later, which is the honest case for killing more things than feels comfortable.

So the reframe: switching something off is finishing it. Decommissioning is work, not the absence of work. An off switch is a deliverable, and a written retirement is a record of judgement. 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.

What should I actually do about it today?

Three questions per item on your list. They take about a minute each.

Is it running? Yes, no, or don't know. "Don't know" is an answer, and it's the one that means go and look now.

What can it reach? Files, inbox, calendar, contacts, anywhere it can post. Specifically, not vaguely.

Who reads what it produces? If the answer is nobody, you have two options and "leave it" isn't one of them: either someone starts reading it, or it gets switched off properly.

Then act on the answers. Most items resolve to "switch off, revoke, delete" and take ten minutes each. A few turn out to be quietly doing real work, which is a pleasant surprise and a candidate for the Finish column.

The point of the week isn't tidiness. It's that a business of one has exactly one person available to notice when something goes wrong, and that person cannot notice things they've forgotten exist. Finishing — including finishing by switching off — is how you keep the number of things you're responsible for equal to the number of things you know about.

Related Decodes

• Finish It: What to Do With the Half-Built AI Projects You Started This Summer — this week's hub and the two-hour clear-out.
• The Decommission Checklist: How to Switch Off an Automation Safely — Friday: the five steps that turn "off" into "ended".
• You Don't Sell the Work. You Sell the Promise Behind It. — what an unowned process quietly puts at risk.
• The 15-Minute AI Review That Keeps You Out of Trouble — the recurring version of this check.

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.

TL;DR: Unfinished does not mean inactive — an automation abandoned months ago can still hold access to your files, still send things, and certainly has nobody reading its output, which makes it a live process with no owner rather than a head start. Three quiet risks follow: access you forgot you granted and never revoked, output going out unreviewed, and a cost line you stopped associating with the project. "I'll come back to it" makes things worse because it converts a decision into a drift, and drift doesn't revoke credentials; meanwhile the head start depreciates every week as you forget how it works and the platform changes underneath it, which is the honest case for killing more than feels comfortable. Ask three questions per item — is it running, what can it reach, who reads what it produces — and treat switching something off as finishing it, because a business of one can only be responsible for the things it still knows about.