Every product I've built started the same way. Not with a market analysis. Not with a competitor audit. Not with a focus group or a survey or a carefully constructed user persona with a stock photo and a fictional name. Every product started with me being annoyed about something and deciding to fix it.
First Out exists because I got tired of guessing where to stand on the tube platform. Little London exists because I have a young son and every weekend involves the same conversation about what to do with him. Trove exists because I hoard bookmarks like a digital magpie and needed a way to make sense of them all. CultureTerminal exists because I read across ten different industries and wanted everything in one place.
Fourteen products. Every single one built for an audience of one. Me. And that isn't a confession. It is the strategy.
The honesty of scratching your own itch
There's a particular kind of honesty that comes from being your own first user. You can't lie to yourself about whether something is useful. You can't fool yourself with vanity metrics or aspirational use cases. Either the thing solves your problem or it doesn't. Either you use it every day or it sits there gathering digital dust. There's no middle ground when you're both the builder and the customer.
I know exactly when First Out is working because I use it every time I get on the tube. Not occasionally. Not when I remember. Every single time. I stand on the platform, check the app, and position myself accordingly. If a feature doesn't help me catch my train faster, it doesn't get built. If a piece of information is missing, I feel the gap personally. The feedback loop is instant and brutally honest.
Compare that to building something on spec - building for an imagined user with imagined needs. You spend months constructing something based on assumptions, then launch it and discover that the assumptions were wrong. The user doesn't behave the way you expected. The problem you thought was urgent turns out to be something people have already worked around. The feature you spent weeks on gets ignored while the thing you threw in as an afterthought becomes the most used part of the product.
When you build for yourself, the assumptions aren't assumptions. They're lived experience. I don't need to guess whether parents in London need a weekend activity guide. I'm a parent in London who needs a weekend activity guide. I don't need to hypothesise about whether people read across multiple industries. I read across multiple industries. The product isn't a bet. It's a solution to a problem I experience every day.
User zero
In product development, there's a concept of the "early adopter" - the first users who try something new because they're excited by novelty and willing to tolerate rough edges. But before the early adopter, there is user zero. That's the person who built the thing. And if user zero doesn't genuinely use and care about the product, it shows. It always shows.
You can tell when someone built something they actually use. The details are right. The flow makes sense. The things that should be easy are easy, and the things that should be prominent are prominent. Not because someone did extensive user research, but because the builder lives inside the problem and understands it intuitively. The empathy is real because it is self-directed.
Little London has a "this weekend" filter because that's how I think about activities - not next month, not in general, but this specific weekend, with my son, in this specific weather. That feature exists because I needed it, not because a product manager wrote it into a roadmap. The distinction matters because the feature works exactly the way it should - it isn't a checkbox on a feature list, it's a genuine solution to a genuine problem.
The same principle applies to Trove. I save hundreds of links a month - articles, tools, references, rabbit holes. Before Trove, they disappeared into browser bookmarks, never to be found again. Trove exists because I needed a way to surface patterns in what I save, to understand my own taste through the lens of what I collect. I'm not guessing that this is a useful feature. I'm using it right now, today, to organise the links I saved this morning.
The audience shows up later
The thing about building for an audience of one: if the problem is real for you, it's almost certainly real for other people too. You aren't that unique. Your frustrations, your needs, your daily friction points - other people have them too. They just have not built anything to solve them yet.
CultureTerminal started as a way for me to aggregate the RSS feeds and newsletters I read across culture, tech, brands, and design. I wanted one place instead of fifteen. It turns out that other people who work across industries - strategists, creative directors, brand consultants - want the same thing. They found CultureTerminal not because I marketed it to them, but because the problem I solved for myself was the same problem they had.
This is the beauty of the audience-of-one approach. You don't need to find your audience. They find you. Because when something genuinely solves a real problem, it gets shared. Not because of growth hacking or viral loops or clever marketing. Because one person tells another person "I found this thing that does exactly what I needed" and that person tells someone else. Organic growth based on genuine utility. It is slow. It isn't scalable in the venture capital sense. But it is real.
Permission to be selfish
There's a strange guilt that comes with building things for yourself. The product world tells you to "think about the user" and "be user-centric" and "put the customer first." All good advice, in theory. But it creates this implicit message that building for yourself is somehow selfish or navel-gazing. That you need external validation before something is worth building.
I want to push back on that. Building for yourself is the most user-centric thing you can do - because you're a user. A real one. With real problems and real opinions and real context about what would actually make your life better. You aren't imagining a user. You're being one.
The best products in history started this way. Slack was an internal tool that Stewart Butterfield's gaming company built for themselves. Basecamp was a project management tool that 37signals built for their own web design agency. Instagram started as a check-in app that Kevin Systrom built because he wanted to share photos of what he was doing. The founders were user zero in every case.
I'm not comparing my fourteen weekend projects to Slack or Instagram. The scale is laughably different. But the principle is identical. Start with a real problem. Build a real solution. Use it yourself. See who else shows up. That's the whole strategy. It isn't complicated. It isn't clever. It is just honest.
The next product I build will start the same way. Something will annoy me. Some daily friction point will nag at me until I can't ignore it anymore. And I'll open Claude Code on a Saturday morning, describe the problem, and start building. Not for a market. Not for a demographic. For me. An audience of one.
And then I'll see who else shows up.
