Why I built task decay: the case against keeping every todo forever
Why I built task decay: the case against keeping every todo forever
I exported my Todoist account before I deleted it and the file had 1,847 tasks in it. I had been a Todoist user for about three years. Subtract the ones I’d actually completed and there were still roughly 1,100 open items in that account. I had not looked at most of them in over a year. I had not done most of them. I was never going to do most of them. And the app had, every day for three years, kept them for me.
The pitch for that storage is “peace of mind.” You can trust the app not to lose anything. Your brain can let go.
That is not what it did to my brain. It is the opposite of what it did to my brain.
The backlog is not a neutral place
There is a specific paper I want you to know about. Masicampo and Baumeister (2011), published in the Journal of Personality and Social Psychology, ran five studies on what unfinished goals do to cognition. The short version: unfinished goals cause intrusive thoughts during unrelated work, high mental accessibility of goal-related words, and measurably worse performance on unrelated anagram tasks. This is the mechanism behind the older Zeigarnik effect, the one you’ve probably heard about, which argues that unfinished tasks stay cognitively active in a way that completed ones don’t.
What’s more interesting is the fix Masicampo and Baumeister found. You don’t have to do the task to clear the intrusion. You just have to make a concrete plan for it. Planning releases the tension. The brain treats “this has a plan attached” as close enough to “this is done” for the purpose of shutting up about it.
Now read the backlog in that light. 1,100 open items. Almost none of them have plans attached. They are all in the “unfinished goal” bucket, each one leaking a tiny bit of cognitive tension. The official productivity frame is that the backlog is reducing cognitive load because you’ve offloaded it to the app. The research suggests the opposite: an unplanned task in a list is still an unfinished goal in your head. The app didn’t take the weight. It made a copy of the weight and handed it back to you.
For neurotypical users, the ratio works out. Enough tasks get done, enough tasks get planned, the backlog stays manageable. For ADHD users, the ratio collapses. The rate of capture exceeds the rate of completion by something like an order of magnitude, so the backlog compounds, and every re-read of the list is a re-encounter with 1,100 unfinished goals at once.
That’s the graveyard. And the graveyard does damage every time you walk past it.
What happens when an ADHD brain re-reads a dead task
Open Todoist at the end of a bad week. Scroll to a task from fourteen months ago: “Book dentist appointment.”
Four things happen in roughly this order, each one costing working memory:
- Recognition. I wrote that. I remember writing that.
- Context reconstruction. Was this the annual cleaning or the filling? Which dentist? The one I stopped going to because of insurance? Did I end up going anyway?
- Moral assessment. I have not been to the dentist in fourteen months. Is this a problem. It’s probably a problem.
- Decision deferral. I don’t have the energy to sort this out right now. I’ll look at it later. Snooze.
Multiply that by the fifty other fossils in the list. By item twelve I have spent my decision budget for the day and not actually done any of the work I opened the app to do. I close the app. The tasks are all still there. The app is still holding them for me, patient and silent, which is the thing I was told was a feature.
The common term for this is “overwhelm.” The less common term is accurate: it’s motivational decay compounding with working-memory exhaustion, compounding with ADHD-baseline guilt about unfinished tasks. Each dead entry takes something. The app cannot distinguish a live task from a dead one, so it charges me the same cost for both every time I open the list.
The case for letting things fade
Task decay, in Ikoi, is simple. A task you haven’t touched in N days (configurable, default twenty-one) starts fading visually. If you keep not touching it, it eventually disappears from the main list. It isn’t deleted. It’s archived behind a specific gesture if you ever want it. But the default surface of the app stops asking you about it.
The usual objection is data loss. I’ve heard this one dozens of times. It is the most important-sounding objection and the weakest one. Three responses:
- A task you haven’t touched in three weeks is almost never a task you’d have done if the app had kept reminding you. The reason it’s untouched is not that the app failed to surface it enough. It’s that it isn’t the right task for this period of your life. The app continuing to surface it is the failure mode, not the fix.
- Truly important things don’t decay quietly. If the dentist appointment is actually urgent, the world tells you, usually with a toothache. The tasks that decay are the ones the world is not asking for.
- Re-capture is cheap. If a decayed task genuinely matters, writing it again takes ten seconds. The cost of re-capture is less than the cost of carrying 1,100 intrusive half-goals in your list for a year.
The deeper argument, the one that won’t fit on a settings tooltip, is that the backlog is not a memory. It’s a weight. The only way to make it not a weight is to let parts of it go. Manually, you won’t. (I didn’t. I had three years of proof I wouldn’t.) The app has to do it for you, by default, with a gesture that feels less like deletion and more like the task politely excusing itself.
Why Todoist and Things can’t ship this
Every time I describe task decay to a productivity-app person, the same reaction: interesting, but we could never ship that to our users. They are correct. They can’t.
Todoist, Things, TickTick, ClickUp, Notion, and the rest are built for an audience whose relationship with their backlog is trust-based. These users put things into the app because they trust the app to keep them. The implicit contract is infinite storage. Silently fading tasks would break that contract for the 80% of users who don’t have an ADHD backlog problem. The complaints would be immediate and loud: the app ate my stuff.
So these apps ship the opposite. Todoist has karma points for completion streaks. Things has beautifully persistent “Someday” lists. TickTick has “archived” as an explicit, heavyweight gesture you must perform. All of it optimized to reassure the user that nothing is lost. All of it actively making the graveyard bigger.
This is one of the clearer cases I know of where “serve the general user” and “serve the ADHD user” point in opposite directions. A feature that is a bug for median users is the right feature for ADHD users. An app that wants to serve both ends up picking one.
Ikoi picks the ADHD user. The decay is on by default. The threshold is adjustable. The “I want to keep this” gesture is available but deliberately more work than the “let it fade” default, because the whole point is to flip the default in the direction that reduces the graveyard.
If you want infinite storage and never want a task to fade, other apps already do that excellently. This is not the one.
What to take from this
If you are building for ADHD users: the backlog is not a value-add. It is the enemy. Every task you store without a plan is a tiny cognitive intrusion you handed back to the user. Architectural consequences follow, and none of them are cosmetic.
If you are an ADHD user trying to pick a tool: watch how the app treats old, untouched tasks. If it keeps them forever in a default-visible place, it is architecturally aligned against you, no matter how nice the onboarding is. If it has any mechanism for letting old tasks quietly leave (decay, auto-archive, weekly cleanup prompts), that is the single most load-bearing feature you can look for.
The test isn’t “can this app hold a lot of tasks.” It’s “can this app let go of one.”
Related reading: Todo apps aren’t built for ADHD brains covers the six assumptions that produce the graveyard in the first place, and ‘Not today’ is a feature, not a failure covers the deferral side of the same problem.