Useful Tools Start as Annoyances

I almost never start with "I want to build a product."

I start with something that keeps interrupting me.

That sounds less strategic than it should. Most advice about building useful tools begins with markets, validation, and user interviews. None of that is wrong. It is just not how the tools I stay attached to have usually begun.

The pattern is simpler: a workflow is almost fine, but not quite. The same gap keeps appearing. Eventually the workaround becomes more annoying than building the fix.

The useful annoyance is always specific. Not "video learning is inefficient." More like: "I watched this conference talk twice and still cannot find the section that explained the WebSocket implementation." That kind of specific. That kind of stubborn.

¶NoteWise

I like learning from long technical videos. Lectures, conference talks, deep-dive tutorials — they build intuition in a way short posts often do not.

The problem appears a week later.

The part I needed is buried inside a video I watched once. Rewatching is expensive. My memory keeps the feeling of understanding, not the understanding itself. I wanted the substance of the video in a form I could actually return to.

That became NoteWise: YouTube videos into structured Markdown notes, organized by chapter when possible, useful enough to replace rewatching.

The rest came from that one requirement. Multi-provider LLM support through LiteLLM. SQLite caching so I would not reprocess the same video. Batch input from a text file of URLs. A notewise doctor command. Proper PyPI packaging and versioning.

Those features were not added because they looked good on a feature list. They survived because I kept using the tool and kept feeling where it broke.

¶GitResume

GitResume came from a different kind of friction.

I kept seeing engineers describe strong work in weak language. Real projects with careful tradeoffs, specific implementation details, and hard-won context would turn into vague resume bullets. Generic verbs. Generic impact. Nothing that showed what actually happened.

That is not only a writing problem. It is a translation problem. Explaining a codebase to someone who was not there requires a different process than building it.

GitResume points at a repository and reads structure: imports, file patterns, function signatures, language choices, and project shape. Then it turns that into descriptions grounded in what the code actually does.

The goal is not to inflate the work. The useful version is more honest than that. It phrases the truth with enough specificity that the work can stand on its own.

¶Finance Manager

Finance Manager is the plainest example, which is probably why it worked.

I was tracking hostel expenses in a spreadsheet that kept getting messier. Personal finance apps wanted more access than I wanted to give, or they assumed a lifestyle that was not mine.

So I built the version I needed: category budgets, cleaner reporting, direct control over the data, and a security model I was not embarrassed by.

It has two stars on GitHub. It is not a successful open-source project in any conventional sense. But I have used it long enough that I no longer think of it as a project. It is just the thing I use to understand my money.

That is the cleanest version of the pattern: the annoyance stopped.

¶The Filter

Annoyance is a useful design filter because it gives you a real user from day one. You are the user. You cannot fake whether the tool helps.

It also gives you a clear failure condition. If the irritation is still there, the tool failed.

That pressure keeps product direction honest. Features that sound impressive but add friction become obvious quickly because you have to live with them.

Portfolio projects often grow sideways: more features, better demos, broader claims. Annoyance-driven tools grow forward. They move toward the thing that keeps bothering you until it stops.

¶Scope Gets Easier

When a project begins with a real irritation, scope decisions get clearer.

I prefer boring reliability over architectural cleverness. I keep local usefulness above README impressiveness. I remove features that look clean in theory but slow down the actual workflow.

NoteWise could have become much larger. Most of the ideas I dropped would not have made it better. They would have made it slower to set up, harder to trust, and less likely that I would keep using it.

The annoyance is an anchor. It keeps asking the only question that matters: does this help with the thing that was bothering me?

¶The Larger Version

This is not only a side-project habit.

The best systems work I have seen usually starts with someone being bothered by exactly the right thing: a repeated failure mode, a confusing operator workflow, an interface that hides the wrong information, a process that creates unnecessary drag.

The scale changes. The stakes change. The instinct is the same. Someone keeps running into a problem until building the fix becomes the clearest path forward.

¶The Signal

The tools I trust most are rarely the ones I planned most carefully.

They are the ones that started as a sentence in the back of my mind while I was trying to do something else. A sentence I kept returning to until I built the thing just to make it stop.

This should not work as well as it does. And yet.

Useful software often has that quality. It exists because someone was annoyed enough that it did not exist. The need is real, the user is present, and the failure condition is known before the first line of code is written.

I do not know how to generate that signal on demand. But I trust it when it shows up.