Why GTD Fails for Side Projects

GTD Is a Great System. For Someone Else's Problem.

You've read the book. You've set up the system. You have a trusted inbox, context lists, a weekly review ritual, and the right app.

Your side projects are still unfinished.

Getting Things Done by David Allen is the most respected productivity system ever published. It's been around since 2001, sold millions of copies, and built a community of practitioners who swear by it. For managing a high volume of external inputs — emails, meeting requests, phone calls, delegated tasks, follow-ups, commitments made in hallway conversations — GTD is probably the best system ever invented.

But here's the thing: GTD was designed to manage incoming obligations. Side projects aren't obligations. They're creative commitments you made to yourself. And the system that works for processing your email inbox actively works against shipping a side project.

If you're a solo developer working on side projects, you don't have an input problem. Nobody is emailing you about your side project. Nobody is requesting features for the thing that doesn't exist yet. Your problem isn't that you have too many inputs to process. Your problem is that you have too many ideas and you can't finish any of them.

That's why GTD fails for side projects. It's a system built to process what comes in from the outside world. Solo developers building side projects need to stop generating new work and finish the work they already started.

Discussions on Hacker News about developer productivity consistently surface the same pattern: developers set up GTD, run it for two to four months, and then abandon it because the maintenance overhead consumed the time they needed for building.

How GTD Is Supposed to Work

Before explaining why GTD fails for side projects, let me give David Allen's system a fair description.

GTD has five stages: capture, clarify, organize, reflect, and engage.

Capture means getting every open loop out of your head and into a trusted system. Anything that has your attention — whether it's a task, an idea, a commitment, or a worry — goes into an inbox.

Clarify means processing each item in your inbox. For each item you ask: Is it actionable? If no, trash it, file it as reference, or put it on someday/maybe. If yes, what's the next action? If it takes less than two minutes, do it now. If it's more than one step, it's a project and goes on your projects list.

Organize means putting everything in the right place. Next actions go on context-based lists (@computer, @phone, @errands, @office). Projects go on the projects list. Waiting-for items go on a waiting-for list.

Reflect means doing a weekly review. You go through every list, every project, every waiting-for item, and make sure everything is current.

Engage means actually doing the work. You look at your context list, scan the available actions, and pick one.

It's elegant. It really is. The problem isn't the design. The problem is the assumption. GTD assumes your bottleneck is managing all the stuff that life throws at you. For a solo developer building side projects, that assumption is wrong.

Why It Breaks Down for Solo Developers

"Capture Everything" Is Scope Creep with a System

GTD's most famous principle is "capture everything that has your attention." Every idea, every thought, every "oh I should probably..." goes into the inbox. This is supposed to give you peace of mind.

For a solo developer with side projects, this is gasoline on a fire.

You already have too many ideas. That's not the problem you need to solve. GTD says: capture all of that. Write it down. Put it in the inbox. Process it later.

So you do. And now you have an inbox full of project ideas, feature concepts, half-formed product thoughts. You clarify each one. Some go to someday/maybe. Some become projects. Some become next actions. Your system grows. Your lists expand. Your weekly review takes longer.

And you still haven't shipped anything.

The capture habit — which is GTD's greatest strength for a busy executive — becomes a developer's most sophisticated form of procrastination. Every time you write down a new idea, you feel a small hit of progress. "I'm being productive, I'm capturing." But writing down an idea is not progress. Shipping is progress.

What you actually need is the opposite of capture everything. You need to ignore almost everything. The idea validation process matters more than the idea capture process. You don't need a bigger inbox. You need a smaller one.

Weekly Reviews Become Guilt Ceremonies

The weekly review is the engine of GTD. David Allen calls it the "critical success factor" for the whole system. Without it, your lists go stale, your brain stops trusting the system, and the whole thing collapses.

For someone with a demanding job, lots of commitments, and dozens of open loops with other people, this review is worth every minute. It keeps you on top of a complex, fast-moving situation.

For a solo developer working on side projects after hours? You're reviewing a system that hasn't changed much since last week. Your someday/maybe list is the same 30 items it was last week. Your projects list has the same two active projects. Your waiting-for list is empty because you're not waiting on anyone.

The weekly review assumes a high volume of changing commitments. For a side project developer, none of that is true. The review adds zero information. It's ritual without function.

Context-Based Lists Miss the Point Entirely

GTD organizes next actions by context: @computer, @phone, @errands, @office, @home.

For a solo developer building side projects, this is almost comically irrelevant.

Your context is always @computer. That's it. There is no @errands context for your SaaS project. There is no @phone context. You have one context, and it contains every single action on every single list.

What you need isn't a context-filtered action list. You need a sequential list of things to build, in order, for the project you're currently working on. That's a scope list, not a GTD system.

No Kill Mechanism

This is the failure mode that nobody talks about, and it's the one that matters most.

GTD has a place for every idea: inbox, next actions, projects, someday/maybe, reference, or trash. But in practice, the only items that get trashed are things that are clearly irrelevant. Ideas for projects almost never get trashed. They go to someday/maybe. And someday/maybe is a graveyard that you visit every week during your review, where every dead idea stares back at you.

GTD has no mechanism for killing an idea. There's no step where you evaluate a project idea against actual market demand, your available time, your skills, and your goals, and then decide it should die permanently. The someday/maybe list is a holding pattern, not a decision framework.

For a solo developer, this is poison. You need a system that forces you to say no to 90% of your ideas. Not "someday." Not "maybe." No. Kill it. Delete it. Move on.

GTD Is Maintenance-Heavy, and Maintenance Time Is Building Time

Let's add up the overhead. Capture throughout the day (constant small interruptions). Daily inbox processing (10-15 minutes). Weekly review (45-60 minutes). List maintenance. Call it 2-3 hours per week of system maintenance.

If you're a full-time knowledge worker with 40+ hours of work time per week, 2-3 hours of system maintenance is a reasonable investment. It's less than 10% of your time.

If you're a side project developer with 8-10 hours of building time per week? That 2-3 hours of GTD maintenance just consumed 25-30% of your available time. A quarter of your building hours, gone. Not to building. Not to shipping. To maintaining a productivity system.

And here's what makes it worse: the maintenance feels productive. Processing your inbox feels like you're getting things done. Running your weekly review feels responsible and organized. But none of it is building. None of it is shipping.

Your side project doesn't care how organized your lists are. It cares whether you wrote the code.

What to Do Instead

If you're a developer who's tried GTD and wondered why your side projects still don't ship, here's the alternative.

Stop thinking in terms of Capture, Clarify, Organize, Reflect, Engage. Start thinking in terms of Validate, Scope, Lock, Build, Ship.

Validate means spending real time asking whether your idea is worth building at all. Not capturing it for later evaluation. Evaluating it now. Talk to potential users. Search for existing solutions. If the idea doesn't survive validation, kill it. Not someday/maybe. Kill it.

Scope means defining the smallest possible version that delivers real value. Not a feature list. A ship list. What are the 5 to 7 things that must work for v1 to go live?

Lock means closing the scope. No new features. No new ideas added to the list. Everything else goes on a v1.1 list that you don't look at until v1 ships. This is the mechanism GTD lacks entirely. GTD is an open system that accepts unlimited inputs. You need a closed system that rejects new inputs until the current thing is done.

Build means working through your locked scope list, one item at a time, until everything is done. No context switching between projects. No pausing to reorganize your system. Build. I wrote about managing your backlog using exactly this method.

Ship means putting it in front of users. Not "someday." Not "when it's ready." When the scope list is complete, you ship. Then and only then do you open the v1.1 list and start the cycle again.

FoundStep was designed around this Validate-Scope-Lock-Build-Ship model. Instead of giving you an inbox and a someday/maybe list, it gives you a locked scope with binary task states. The system creates friction against adding more work, which is the opposite of GTD's capture-everything philosophy.

The whole thing takes about 10 minutes per week to maintain. Not 2-3 hours. 10 minutes. Because there's not much to maintain. You have one project, one scope list, and binary states for each item.

A Shipping System vs GTD: Side by Side

Here's how the two approaches compare for a typical side project:

Starting a project:

• GTD: Capture the idea, clarify it, create next actions, add to project list.
• Shipping system: Validate the idea against a structured framework. Build, wait, or kill.

Managing scope:

• GTD: Capture every new idea into the inbox, clarify, add to project.
• Shipping system: Lock scope. New ideas go to an Idea Vault for future projects. Adding to current scope requires written justification.

Tracking progress:

• GTD: Check off next actions. Review weekly.
• Shipping system: Move through lifecycle phases. Validate, decide, build, ship.

Knowing when you're done:

• GTD: When next actions stop appearing. (This never happens.)
• Shipping system: When you mark the project as shipped. It goes to Harbor. You get a Ship Card.

Handling stalled projects:

• GTD: Keep reviewing them weekly until you feel guilty enough to either work on them or delete them.
• Shipping system: Ship or kill. No middle ground. Kill it deliberately if it's not moving, and move on with a clean conscience.

When GTD Still Works (and When It Doesn't)

I want to be clear that I'm not saying GTD is a bad system. It's a great system in the right context.

If you're a freelance developer juggling client work, GTD's input processing is genuinely useful. Client emails, project requests, invoices, scheduling, follow-ups. That's a high volume of external inputs from multiple sources, which is exactly what GTD was built for. Use GTD for the business side of freelancing. Just don't use it for your side project pipeline.

If you work at a company and have a demanding job with lots of meetings, commitments, and cross-functional projects, GTD can be a lifesaver.

The common thread is external inputs from other people. GTD excels when the world is throwing things at you and you need to catch, process, and organize all of it. That is not the situation of a solo developer working on a side project on Saturday afternoons.

Your side project has one input source: you. One context: your computer. One goal: ship. This is why GTD fails for side projects: the system is overbuilt for this problem by an order of magnitude.

GTD won't ship your side project. A locked scope and a build-first workflow will. Get started with FoundStep and stop organizing your ideas into a system that was never designed to finish them.