July 2026
Nobody Else's Problems
I have been building software nobody else will ever use, and ignoring the little voice that asks if it could be a product. The ignoring turns out to be the interesting part.
I have been building some software lately that nobody else will ever use.
A tool that reads my YouTube subscriptions and hands me a short digest so I stop drowning in videos. A little learning portal that holds my course notes. The strange editorial machine that helps write this site. An operating system for my life that is mostly markdown files in a folder.
None of it has users. It has a user.
Me.
Every one of them would make a terrible product. Every one of them is an excellent tool.
There is a trained voice that shows up whenever one of these things works. It clears its throat and says: could this be a product? Should you validate it? Surely other people have this problem too.
I have started ignoring that voice. And the ignoring turns out to be the interesting part.
Because the moment you care whether your problem is anyone else’s problem, you start ruining the solution. You sand off the specific bits. You add settings for imaginary users. You stop solving your problem and start solving a rough average of everyone’s.
Products have to do this. A product serves the overlap, the slice of the problem everyone shares.
But most of my actual daily friction does not live in the overlap. It lives in the corners. Too specific, too tangled up with my exact calendar, my exact workflow, my exact weirdness. No product is coming for those problems. Not because they are small. Because they are mine.
That is software you cannot buy. You can only make it.
And when you make it just for yourself, you get to be scandalously specific. My name is hardcoded. The file paths are hardcoded. There are assumptions everywhere and not a single settings page, because settings are for imaginary users and I do not have any.
In a product, these are defects. Here, they are precision.
Even the best product serves you approximately. Your own tool serves you exactly.
The feedback loop is also embarrassingly honest. No dashboard. No user interviews. No metrics to argue about. Either I used the thing today or I did not. If I did not, it quietly dies, and it cost me an evening, so nobody mourns.
Nothing is ever finished either, which sounds bad but is not, because there is no ship date. The tool just gets worn in, like a shoe. Every annoyance becomes a small edit. It slowly shapes itself to my life instead of to an average user, who is nobody.
What changed recently is the price. This kind of software used to be a fantasy, or a weekend you would never actually spend. Now it is an evening. Sometimes an hour.
And when solving your own problems gets that cheap, something shifts. An annoyance stops being just a complaint. It can become a prompt.
I am not going to pretend I am excited about problems now. I am not. But I am getting a bit more curious. When something annoys me, there is a new move available: sit down with the AI, see if it can make a solution, iterate the system together, see what happens.
That is the experiment, anyway.
Could one of these tools become a product one day? Maybe. It happens. But it happens as a discovery, never as a plan. The not-caring is load-bearing. The moment I build with one eye on other people, I am back to solving the average problem for the average user, and the tool gets worse.
I am aware of the failure mode, too. Building tools for yourself can become a very sophisticated way of avoiding the actual work. I check now and then that the tools are serving the work, not replacing it.
But mostly this feels like a quiet correction. Software had started to feel like an industry thing. Something you make for a market, with a deck.
Making it for yourself feels closer to keeping a notebook.
Small tools. One user. Nobody else’s problems.
A terrible business.
A great way to live.