The Task System I Actually Stuck With as a Solo Developer

I built a six-column Trello board once. Backlog, Ready, In Progress, Blocked, Review, Done, each with its own color labels and WIP limits I copied from a talk about team Kanban. I was one person. I maintained that board more carefully than I maintained my actual code, and after about four months I quietly stopped opening it. The cards are probably still there, frozen sometime in early spring, a monument to a system that was solving a problem I didn't have.

This post is about what replaced it: a much dumber system built around three buckets and a fifteen-minute weekly review. It's not novel or clever. It's just the thing that survived, and I think the reasons it survived are more useful than the system itself.

The board wasn't even my first attempt. Before it, I tried a paper bullet journal for about six weeks, because I'd read that writing things by hand improved recall. It did, a little, but it fell apart the moment a task needed to move — carrying an unfinished item forward meant literally rewriting it on a new page, and after enough half-finished pages I stopped trusting the journal to reflect reality. The Kanban board was my overcorrection: if paper couldn't move things around cleanly, I'd use a tool built entirely around moving things around. It turned out the actual problem was neither the medium nor the mechanics — it was that I kept designing for a team of one as if it were a team of five.

The Kanban Board That Looked Great and Died in Three Weeks

The board itself wasn't the problem. Kanban works well when multiple people need a shared, glanceable view of where work sits, because the board is doing coordination work that would otherwise happen in meetings or Slack threads. I don't have that problem. I know where my own work is. The board wasn't coordinating anything — it was just a second place I had to update every time I touched a task.

Within the first week I noticed I was doing the work first and updating the card afterward, sometimes days afterward, which meant "In Progress" stopped meaning anything. By week three I had a "Blocked" column with four cards in it that weren't actually blocked, I just hadn't decided whether to do them. The board was accumulating decisions I hadn't made rather than reflecting decisions I had.

What Actually Broke It

• Too many states for one person. A team needs to see who's doing what. A solo dev doing the moving and the doing is just double-entry bookkeeping.
• The board rewarded organizing over finishing. Color-coding a card felt like progress. It wasn't.
• No forcing function to shrink it. Cards could sit in Backlog forever with zero cost, so the backlog grew until it was demoralizing to open.

The System That Replaced It: Three Buckets

What I use now has three lists: Today, This Week, and Backlog. That's the entire structure. No columns for status, no swimlanes, no labels beyond a single tag for client-billable versus internal work, because that distinction actually matters at invoice time.

1. Today holds only what I intend to touch before I stop working, capped at five items on purpose. If something doesn't fit, it doesn't go on Today — it waits.
2. This Week is a slightly looser holding area: things I've committed to landing by Friday but haven't scheduled to a specific day yet.
3. Backlog is everything else — ideas, someday-maybe work, things a client mentioned that aren't urgent. It's allowed to be long. Its only job is to not be Today.

The rule that makes this work is that items only move in one direction: Backlog to This Week to Today to done. Nothing gets re-sorted mid-week. If I discover Tuesday that a "Today" task is bigger than I thought, it doesn't get a new status — it just doesn't get finished, and I look at it again during triage the next morning.

How Capture Works

The board only works if stray thoughts don't get lost, and it only works if capturing them doesn't cost more than a few seconds. I use a single plain-text scratch file that syncs across my laptop and phone — nothing fancier than a notes app set to "quick capture" mode. Anything that occurs to me mid-task — a bug I notice, an email I need to send, an idea for the tool I'm building — goes into that file with zero formatting and zero triage in the moment.

That's the part I got wrong the first time around. My old habit was to stop what I was doing, open the board, decide which column something belonged in, and add labels. That interruption cost more than the task itself half the time. Now capture and triage are separate steps, done at different times, and that separation is the actual productivity gain — not the three-bucket structure.

The Friday Triage Ritual

Every Friday afternoon, before I stop for the week, I go through the scratch file and the Backlog list together. This takes ten to fifteen minutes and follows the same order every time:

• Empty the scratch file — everything in it gets deleted, moved to Backlog, or moved straight to next week's This Week list.
• Look at anything still sitting in This Week that didn't get done, and ask honestly whether it's actually a priority or whether I've been avoiding admitting it isn't.
• Pick five to seven items for the following week's This Week bucket — no more, because that number consistently matches what I actually finish.
• Scan Backlog for anything that's been sitting more than six weeks untouched. Some of it gets deleted outright, which feels bad for about ten seconds and then feels great.

The deleting step matters more than it sounds like it should. A backlog that only grows becomes a source of guilt rather than a resource. Killing stale items on a schedule keeps the list honest about what I'm actually going to do versus what I'm keeping around out of obligation.

When I'm Stuck Choosing What to Do Next

Some mornings I've got three Today items that are all genuinely equally important and I burn ten minutes deciding which to start with, which is a worse use of time than just picking one. When that happens now, I don't overthink it — I'll open the site's own random number generator, assign each candidate task a number, and let it break the tie. It sounds like a joke, but the actual value isn't randomness, it's that it stops the fake-deliberation loop where I'm pretending to be strategic about a decision that doesn't matter enough to deserve strategy.

A Week the System Actually Earned Its Keep

The clearest proof of a task system isn't a calm week, it's a chaotic one. A few months into using this setup, a client emailed on a Wednesday afternoon asking to move up a launch date by nine days, which meant three separate things I'd scheduled for the following month suddenly needed to happen before Friday. Under the old board, this would have meant re-labeling half a dozen cards, moving them across columns, and probably losing track of which ones I'd actually re-prioritized versus which ones I'd just glanced at while panicking.

Instead, I did the whole re-prioritization in about five minutes: dropped the three newly urgent items straight into Today, bumped the two things that had been sitting there back down to This Week, and left Backlog untouched because none of it was relevant to the decision. The system didn't prevent the fire drill — nothing prevents a client moving a deadline — but it meant the fire drill cost five minutes of reorganizing instead of twenty, and I never lost track of what I'd bumped or why, because there was so little structure to lose track of in the first place.

What I'd Tell Someone Setting This Up Today

Start smaller than feels responsible. My instinct the first time was to build a system sophisticated enough to handle every edge case I could imagine — blocked tasks, waiting-on-client tasks, recurring tasks, someday tasks. Almost none of those edge cases showed up often enough to justify their own column. Three buckets and a weekly deletion habit have outlasted every more elaborate system I've tried, mostly because there's so little of it to maintain that skipping a day doesn't break anything.

The other thing I'd say is to resist adding a fourth bucket the first time you feel the urge, because you will feel the urge — usually around week three, right when a "Blocked" or "Waiting" column starts to sound reasonable again. In my experience that urge is almost always solvable by just leaving a note directly on the task itself instead of inventing a new category for it. A task that's blocked on a client reply doesn't need its own column; it needs one sentence appended to it saying what it's waiting on, and it can keep sitting in This Week like everything else until the answer comes back.

If you're automating any part of your own admin work around a system like this — reminders, digest emails, status pings — it's worth looking at what a no-code option like the AI Automation Builder can do before writing custom scripts for it. And if the friction in your week is less about task tracking and more about the number of small manual steps eating your day, I wrote up the actual shortcuts and scripts I use to cut that down in this rundown of keyboard shortcuts and small automations — it pairs well with a task system this plain, since neither one requires much upkeep to keep paying off.