Why I Keep Building New Products Instead of Fixing the Ones I Have

I’ve now written two separate posts explaining why a product of mine lost its Gumroad buy button. Three n8n templates first, then five boilerplates. Both posts land on the same conclusion: a checkout page isn’t a distribution channel, and none of those products sat anywhere a stranger would actually find them. I stand by that reasoning. What I didn’t write about, in either post, is what I did right after reaching it.

I didn’t go fix the distribution problem. I went and built something else.

The pattern, once I looked at it straight

After the n8n templates came down, I didn’t go pitch them properly on n8n.io’s own template library, which was the specific gap I’d just diagnosed. I started packaging a new batch of workflows instead. After the boilerplates lost their buy buttons, I didn’t go build the self-hosted-product equivalent of a plugin directory. I kept writing about the Obsidian plugins, which already had that advantage handed to them for free.

Both times, the honest move after identifying “this needs a discovery layer, not another product” would have been to go build the discovery layer. Both times, I built another product instead. I noticed this the second time, mid-draft on the boilerplate post, and stopped to sit with it rather than write past it.

Why building is the part I reach for

I trained as a textile engineer. Four years in production planning and denim before any of this. That background rewards a specific skill: take a spec, work through it, produce a thing that meets it. Building a plugin, a boilerplate, a workflow bundle, fits that skill exactly. There’s a clear finish line. The code either does the thing or it doesn’t.

Fixing distribution has no clear finish line. It’s writing forum comments that might not lead anywhere, learning whichever platform’s search behavior actually rewards a listing, showing up somewhere repeatedly before anyone notices. None of that resembles engineering work. It resembles the kind of ongoing, unglamorous presence-building that has no equivalent in a spec sheet, and I keep quietly reaching past it for the version of the problem I already know how to solve.

Where this actually holds up, and where it doesn’t

I want to be fair to myself here too. The Etsy shop and the Obsidian plugins didn’t get their distribution by accident. Etsy’s own search is why I wrote a whole post on listing SEO instead of just uploading and hoping. The plugins ride on the Obsidian community, and I’ve kept engaging with that community rather than treating the listing as done once it’s live. So it’s not that I never do the distribution work. It’s that I only seem to do it when the platform hands me an obvious next step, a search box to optimize for, a community thread to join. When the answer is vaguer than that, building wins by default.

What I’m changing, concretely

Not a grand plan, just one rule I’m testing: before I start building the next thing, I write down, in one sentence, where a stranger who wants it would actually be looking. If I can’t answer that sentence honestly, I don’t get to start building until I can. That would have caught the n8n templates and the boilerplates both, before either shipped, not after.

I don’t know yet if I’ll actually hold myself to that. Old habits are exactly this kind of habit. But naming it here means I can’t quietly pretend later that I didn’t see the pattern. I’ve written honestly about a two-sale total and a six-plugin split that didn’t go the way I expected in I built six Obsidian plugins. Two sold., and about walking two product lines off Gumroad in why I took the SaaS boilerplates off Gumroad and why I took three n8n templates off Gumroad. This is the piece underneath all three: knowing the lesson and acting on it aren’t the same thing, and I’ve been better at the first one than the second.