Why I Build Things Nobody Asked For

A few weeks ago someone asked me how I validate ideas before building them. I gave a vague answer about talking to potential users, which was mostly untrue. The real answer is that I mostly build things I personally want to exist, without much validation at all.

This is not advice. This is a confession with some reasoning attached.

The origin story for most of my apps is embarrassing

Lofikofi exists because I wanted a focus timer that also had ambient sounds and a Kanban board and a notes section, and I couldn’t find one that worked the way I wanted. Rise and Rattle exists because I was bored one afternoon and thought making a board game in Flutter would be a good way to learn something. Splashy Sketchpad exists because I kept opening Xcode’s pasteboard for quick sketches and thought there should be something better for that.

None of these started with a survey. None of them emerged from user interviews. There was no problem statement document, no market sizing, no competitive analysis. There was just a person (me) wanting something to exist and deciding to make it.

Patterns is the one that breaks the pattern slightly. That started from a longer period of thinking about mental health tools and what they get wrong, but it was still driven more by conviction than by data.

Why I think building for yourself is actually fine

The received wisdom in product circles is that you should never build something without validating demand first. Talk to customers, run a survey, look at search volume, analyze the competition. Understand the market before you enter it.

I think this advice is correct for some contexts and slightly misleading for others.

If you’re raising money, you need to demonstrate that other people have the problem you’re solving. If you’re building a B2B product, you need to understand procurement cycles and what a buying team actually needs. If you’re doing this full-time and your income depends on it, you should probably know more about your market before you invest six months.

But if you’re a solo builder who can ship something in weeks rather than months, building for yourself first has some real advantages that don’t get discussed enough.

You understand the problem at a depth that research can’t replicate. You know exactly what good looks like because you’re the user. You have genuine enthusiasm for the work because you actually want the thing to exist. And you skip the long validation phase, which in practice often just means you’re spending time deciding whether to build instead of building.

The risk is that you build something nobody else wants. That’s real, and it happens. But for small projects with small teams (or a team of one), the cost of being wrong is a few weeks of work, not a year of runway.

What it costs

Building things nobody asked for has costs that I want to be honest about.

The main one is distribution. When nobody is looking for your thing, you have to find them. This is harder than it sounds. A tea timer app competes with every other timer app in the App Store. A focus timer with ambient sounds competes in a category with established apps that have years of reviews and loyal users. A niche OCD journaling app serves a small audience by definition.

I am not good at distribution. This is something I know about myself. I build well and I market poorly, and the result is that my apps have smaller audiences than they probably should. Some of this is fixable if I were more systematic about it. Some of it is just the reality of building products people didn’t know they were looking for.

The other cost is motivation. When you build for yourself, you usually solve your own problem before other people’s problems, which means the itch you were scratching is gone before the product is fully polished. The last 20% of any app is the hardest, and it’s even harder when you no longer personally need the thing you’re building. I’ve half-finished features for Lofikofi that I never shipped because by the time I got to them, I’d already moved on from the problem.

Why I keep doing it anyway

Because the alternative, building things other people tell me they want, has its own costs that are harder to see.

When you build for a customer you interviewed, you’re building for one person’s description of their own behavior, which is not the same as their actual behavior. People are unreliable narrators of their own needs. They tell you what they think they want, which is filtered through what they think sounds reasonable, what they’ve seen before, and what they think you want to hear.

When you build for yourself, you have the actual behavior, not the description of it. You know exactly when the existing solutions fail because you’ve been failing with them.

The apps I’ve built that I’m proudest of are the ones I built because I genuinely couldn’t find something better. They’re not all successful by conventional metrics. But they exist, they work, and at least one person (me) uses them and is glad they exist.

That sounds like a low bar. Maybe it is. But it’s a real bar, which is more than I can say for a lot of things that get built with careful validation and end up unused.

I’ll keep building things nobody asked for. The plan is to eventually get better at telling people they exist.