For engagement sake: Ship one thing

I had done it, the minimal working version of my Obsidian plugin was working. I could now explore my notes by their meaning. In the meantime, I was compiling this whole list of features I wanted to add; NLP clustering, multi-modal support, local LLM summarizers, automatic titles, and so on. The thought of having all those features was exciting.

Though, something made me uncomfortable at that feature list. Perhaps it was an intuition that I built over my engineering years. Queue flashbacks of countless products, PM's and stakeholders that over-invested in a feature set, killing the main value driver. Now, in my own project, I saw why it was so appealing. And I was facing the choice; expand the feature set, or harden and simplify the value the plugin offered.

Simple is the most difficult

Here's the thing people can underestimate about that choice; the simplification version was actually the hard one. This whole plugin runs locally, inside Obsidian's sandboxed environment, single-threaded. Every one of those features on my list (the clustering, the summarizers) would've been a new thing fighting for the same tiny pool of compute, on a thread that also needs to stay responsive while you're typing.

Adding features wasn't the most value-yielding path I was telling myself it was. It was the path that suffocated the one thing the plugin actually promised to do.

So I chose the simplification route. I reduced and removed as much as I could, tested alternatives to the more complex parts, simplified what I could. The result? Same functionality, half the code, much easier to understand (a courtesy for my future self). And through solving some misunderstandings, indexing was speed and accuracy increased by 30% (!!).

Battle-testing

The next thing to do is use it—a lot. Something I've found incredibly valuable is using the products you make. It sounds obvious when you say it out loud, but—my fellow developers—how often have you actually actively used the thing you built for a client, or even for yourself?

After some use I caught myself disabling my own plugin, because it'd hang the UI for a split second—very disruptive when you're writing. That stung a little. I added debouncers, which helped, but wasn't enough. Around that same time the community started engaging more, and I got some great feedback. One person was honest in saying they stopped using it after five minutes, because the initial indexing step took too long and too many resources. So I added a task queue for the heavy processes, and gave control over what and when to process. Now the most relevant notes get indexed first, the plugin is immediately useful, and I could pause processing whenever the UI needed to stay responsive. Same single feature—just better, lighter, and friendlier now, even though heavy work was happening underneath.

Retrospect

What's left is a dependable core; simple and dependable semantic search. And in retrospect, a big part of me believes the focus on simplifying is what enabled the engagement. In a previous post I wrote about attention becoming a scarcer commodity. Throwing dozens of half-baked features at people doesn't feel generous, it feels like a demand—it causes decision paralysis and disengagement. Not because the product is bad, it's not that personal; it's that we're all squeezed for attention, and disengaging when too much is asked of us is almost becoming a survival response.

So I offered one (seemingly) simple thing by hiding as much complexity as I could, I smoothed the user experienced, and left the user to just experience the one thing; exploring their notes by meaning. And here's the part I didn't expect; because there was only one legible thing, the effort for people to tell me exactly what was and wasn't working became much less. The feedback came back freely, immediately, without me asking.

Conclusion

Thinking back to that feature list I wanted to start on. Every item on it would have made the plugin more impressive to describe, and worse to use—and it would've buried the signal I actually needed from my users under noise.

Discipline lies in what not to build.

Not to say you can't experiment, A/B test, or build what you like--but to pay attention and effort towards a less demanding user experience.

If you take one thing from this; one thing that's reliable and useful will beat ten things that aren't. And your users will be able to afford to spend the most useful currency there is; attention and engagement.