I built

The leading tool hadn't shipped in four years

I want to start with the original mistake, because it set up everything else.

When I first looked for a text expander for Obsidian, there was already a leader. Stable plugin, decent download numbers, well-known. I tried it, and it did the basic job. But it had no idea what markdown context it was in. Triggers expanded the same inside a fenced code block as in a normal paragraph.

That sounds harmless until you write about code — document a CLI command literally named todo, and the expander quietly turns your example into - [ ]. In a notes app built for developers, that's not an edge case.

I checked the GitHub repo. Last release: four years ago. Issues open: many. PRs ignored.

My first reaction was "this can't be right, I must be missing something." I read other people's plugin reviews, dug through issues, considered forking. Eventually I accepted the obvious thing: in a niche this small, "leader" doesn't always mean "active." Sometimes it just means "first."

Here's the part I didn't expect. When I sat down to fix the code-block bug in my own plugin, it took about fifty lines. Three small pure functions — one for fenced code, one for inline backticks, one for YAML frontmatter. Each one walks the document up from the cursor, counts the delimiters it cares about, and answers a yes-or-no question: is the cursor inside?

The only piece with any real subtlety is fenced code: you have to remember which delimiter opened the fence (backtick triple vs tilde triple) so you don't close one fence with the other. Get that wrong and expansion silently fires inside code blocks again, and nobody can tell you why.

Four years. That’s how long the long-standing leader of the niche had gone without a release — not because the fix is hard, but because nobody was paying attention to the repo anymore.

The lesson that took me nine months to actually internalize: most niche tool categories have abandoned leaders. Not because the maintainers are bad people. Just because attention is finite, and niches don't pay back the maintenance cost for most people. If you find a tool category where the top result hasn't shipped in years, that's not a crowded market. That's an empty one.

The bar to clear isn't "be excellent." The bar is "ship the obvious fix nobody got around to."

Documentation is positioning, not description

Most opensource projects document what they do. Smart projects document when they're the wrong choice.

It took me about four releases to figure this out. Early Snipsy README was a feature list: hotstrings, custom snippets, multi-line expansion, community packs. The kind of README you write when you're proud of what you built.

The problem with that README is that it answered the wrong question. People landing on the page weren't asking "what does this do?" They were asking "is this for me?" And a feature list doesn't answer that.

So I added a section called "When Snipsy is NOT the right tool." It lists three alternatives:

is the dominant system-wide text expander — the one you reach for when you want expansion to work in any app, not just the editor you're in. It also has something Obsidian plugins almost never have:

The packs themselves are open source. Anyone can submit a new pack as a pull request to the Snipsy repo — no marketplace, no review queue, no monetization. This sounds trivial but it's the load-bearing piece: monetization would have killed it. Nobody contributes a fifty-line YAML file to a marketplace. They contribute it to a free community catalog that has their handle in the credits.

One small UX decision made the whole thing work: import preview. When you install a pack, Snipsy shows you a diff before anything touches your settings — added rows in green, conflicting triggers highlighted in red, an explicit prompt for each collision. Without that modal, users would never install a second pack — they'd be afraid the new one would silently overwrite their custom triggers. With it, installing five packs in a row feels safe.

I added the Packages tab in release 12. Downloads roughly doubled in the following month. The first-thirty-seconds experience went from "configure everything from scratch" to "pick a pack, start typing."

Look sideways.

Beating the current leader head-on is rarely the most interesting opportunity in a niche. The higher-leverage move is usually to bridge what a neighboring ecosystem has solved that yours hasn't.

What I'd do differently

Three things, if I were starting Snipsy today.

First, I'd add a CHANGELOG from release one. I started writing proper changelog entries around release eight, which means the first seven releases have garbage notes that look like "fixes and improvements." When someone asks "what changed in version 0.5?" I have no good answer. Changelog discipline is cheap on day one and expensive to retrofit.

Second, I'd publish to the community catalog earlier. I sat on Snipsy in a private repo for about two months because I wanted it to be "ready." It wasn't ready when I published, either. It was just less embarrassing. Published-and-imperfect beats private-and-polishing every time, because feedback is the only signal that matters.

Third, I'd write the "when NOT to use this" section before the "what this does" section. Positioning before feature listing. I figured this out by accident; I'd do it on purpose now.

The bigger pattern

If I zoom out, the through-line across all of this is: indie OSS rewards constraint, not ambition. The temptation, on every release, is to add more. The discipline is to add less, document better, and ship boring infrastructure that keeps you from burning out.

Snipsy isn't a remarkable plugin. Text expansion is a solved problem. But solved problems with abandoned leaders are exactly where indie projects have the most leverage, if you're willing to keep the scope small and the maintenance sustainable.

If you maintain a niche tool — Obsidian plugin, VS Code extension, browser extension, whatever — has anyone tried the "when NOT to use this" section in their own README? I'm curious if it changed who showed up to your issue tracker.