The Quiet Sabotage: Why Most of My Dead Projects Died of Overthinking

Source: Dev.to

Introduction

Kevin Lynagh published a short essay this week about how he sabotages his own projects by overthinking, scope creep, and structural diffing. He spent four hours researching semantic‑diff tools when he only needed an Emacs shortcut, and hundreds of hours on background research for a Clojure‑Rust hybrid and a constraint‑based CAD tool—neither shipped. The piece landed on me hard because I have been keeping a list of projects I killed without shipping.

Patterns of Dead Projects

• Over the last three years I have killed about forty projects and shipped twenty.
• For every one I ship, I kill two.
• The market and competition never killed these projects; I killed them by thinking too hard before building.

Every dead project has a research graveyard in my notes: deep reads on niche architecture choices, benchmarks of libraries I would never actually use, comparison tables of state‑management patterns—all collected before I wrote a single line of code.

The Research Graveyard

The depth of research is always disproportionate. I might be four layers into a Rust async runtime before I have drawn the UI flow, or know the latency trade‑offs of three vector databases before I know if my users need vector search at all. The research feels productive because the notes fill up, but it is actually procrastination in a smart hat.

The tell: if you have spent more time on research than on the smallest shippable version of the thing, you are not researching—you are avoiding commitment.

Real‑World Examples

• Kevin’s shelf project: Hundreds of hours on a programming language meant to build a CAD app that was supposed to design a shelf. The shelf never got built.
• My analytics view: I wanted a simple bar chart of the last 30 days. By the time “planning” finished, I had a write‑up for a self‑hosted Plausible alternative. Neither the bar chart nor the OSS analytics platform ever shipped.

When scope creeps before you have a mile‑one in production, the original need gets orphaned. The orphan dies quietly because the new scope is now too ambitious for a single weekend, and you already have a day job.

The Yak‑Shave Trap

You are about to start a project, open your editor, and feel something is off. You spend a Saturday tweaking dotfiles, configuring a new terminal, rebuilding your font‑rendering pipeline… By Sunday night you have not written a line of the project, but you have a beautiful terminal.

The yak‑shave feels adjacent to real work because it involves tools, and tools are productive—only if the thing they enable is also happening.

Sanity Check

If the task you just started is not the project and does not directly unblock the project within the next hour, close the tab.

The Minimal Shipping Process

None of this requires prep research. It requires picking a small wedge and accepting that the first version will be wrong in ways you cannot predict.

Choosing Tools Wisely

When I catch myself about to open another tab for research, I ask:

• Can I make progress with a slightly worse tool?
• Do I need the semantically‑correct diff tool, or can I use git diff and move on?
• Do I need a vector database, or can I use SQLite full‑text search for the first 1 000 users?
• Do I need a real design system, or can I use Tailwind defaults and ship?

The answer is almost always yes. The worse tool is usually enough, and the time saved goes into actual product development.

Embarrassment as a Signal

I stopped asking “what is the right way to do this?” and started asking “what is the smallest thing I can ship that would embarrass me in a useful way?”

If v0.1 makes you flinch when users see it, that flinch tells you what to build next. If v0.1 is polished, you have over‑scoped and you will not learn what actually matters.

My most successful products all embarrassed me at launch:

• theSVG shipped with 400 icons when the category leader had 10 000.
• Stacklit shipped with a single compression algorithm when more sophisticated approaches existed.
• Glin‑Profanity shipped for one language.

Each succeeded because the first version landed and users told me what to fix.

Lessons Learned

• The top regret is not the projects I started and did not finish; it is the projects I kept alive for eight months of quiet background worry before admitting they were dead.
• Each eight‑month zombie cost me a weekend per month in research and note‑taking, while producing nothing.
• If you have been working on something for more than sixty days without a shipped version anyone has touched, you are probably not going to finish. Kill it. The grief is shorter than the slow bleed.

Overthinking sabotages projects not because thinking is bad, but because thinking without a deadline is. Without a shipping date, every new piece of information looks like it might matter, and the project drowns in adjacency.

Call to Action

Build the small thing. Ship the bad thing. Let users tell you what the good thing is.

Do you have a graveyard? What killed the projects you did not ship? Comments open.