Kevin Lynagh published a short essay this week about how he sabotages his own projects by overthinking, scope creep, and structural diffing. Four hours researching semantic diff tools when he needed an Emacs shortcut. 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.

My list is of projects I killed without shipping. Over the last three years it has grown to about forty. In the same window I shipped twenty. So for every one I ship I kill two.

The patterns of the killed ones are almost always the same. Market did not kill them. Competition did not kill them. I killed them by thinking too hard before building.

The three ways I sabotage a project

1. Researching the wrong depth first

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 of it collected before I had written a single line of the thing I wanted to build.

The depth is always disproportionate. I am four layers into a Rust async runtime before I have drawn the UI flow. I know the latency tradeoffs of three vector databases before I know if my users need vector search at all. The research feels productive because the notes fill up. The research 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.

2. Scope creep before mile one

Kevin's essay names this directly. He spent hundreds of hours on a programming language that was meant to be a tool to build a CAD app that was meant to design a shelf. The shelf never got built.

I do this constantly. A recent example: I wanted to add a simple analytics view to one of my tools. By the time I finished "planning," I had a writeup of how to build a self-hosted Plausible alternative because I did not want to pay for SaaS analytics for the other thirteen products I run. The scope went from "bar chart of last 30 days" to "OSS analytics platform." The bar chart never got built. The OSS analytics platform also never got built.

When the scope creeps before you have 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.

3. Tooling yak-shaves dressed up as foundational work

This is the subtle one. You are about to start the project. You open your editor. The editor setup feels slightly wrong. You spend a Saturday on a new dotfiles config. The config involves a new terminal. The new terminal does not render your font correctly. You rebuild your font-rendering pipeline. By Sunday night you have not written a line of the project and you have a beautiful terminal.

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

I have learned to run a sanity check: if the task I just started is not the project, and does not directly unblock the project within the next hour, I close the tab.

What actually ships

Every project I have shipped followed the same shape. Not "planned carefully." Not "researched thoroughly." The shape is:

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.

The heuristic I now use

When I catch myself about to open another tab for research, I ask: can I make progress on this 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 almost always enough. The time saved goes into actual product.

One specific reframe that helped

I stopped asking "what is the right way to do this." I started asking "what is the smallest thing I can ship that would embarrass me in a useful way."

The embarrassment is the signal. If v0.1 makes you flinch when users see it, that flinch will tell 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. Every one of them got where they are because the first version landed and users told me what to fix.

The projects I should have killed sooner

Looking at my graveyard, 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 of those eight-month zombies 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.

The uncomfortable conclusion

The reason overthinking sabotages projects is not that thinking is bad. Thinking is fine. Thinking without a deadline is the problem. Without a shipping date, every new piece of information looks like it might matter, and the project drowns in adjacency.

Kevin's shelf project worked because he gave it a weekend. Mine work when I give them one too. When I do not, they join the graveyard.

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.