Nobody asked for a pub guide built by a strategist from Nottingham who doesn't even drink. Nobody asked for a wearable tech news aggregator. Nobody asked for a quiz about Nottingham Forest's 1959 squad. Nobody asked for a tube exit guide, a Japanese learning app, or an AI-generated gallery of modern brands reimagined as 1970s retail stores.
I built all of them anyway. Fourteen live products, to be exact. Not a single one started with market research, a user interview, or a validation exercise. Every single one started the same way: I wanted it to exist, it didn't, so I made it.
People in the startup world would tell you this is the wrong way to build things. They would tell you to validate first, to test the idea, to find product-market fit before writing a line of code. And for a certain kind of product, built by a certain kind of company, with a certain amount of investor money on the line, they're probably right. But for the kind of things I build? The validation model misses the point entirely.
The myth of validation
Lean startup methodology has become gospel in the tech world. Validate before you build. Test the idea. Find product-market fit. Run surveys. Build an MVP. Measure everything. Iterate based on data. It's a perfectly reasonable framework for reducing risk when you're spending someone else's money.
But here's what that framework optimises for: safety. It optimises for not being wrong. And when you optimise for not being wrong, you end up building things that are predictably adequate. Things that tick boxes. Things that a focus group would approve. Things that nobody hates and nobody loves.
The most interesting products in history weren't validated. They were believed in. The Walkman wasn't the result of user research - Akio Morita at Sony built it because he wanted to listen to music on the go and nobody could talk him out of it. Tumblr wasn't the output of a lean canvas exercise. The original iPod was dismissed by critics who said nobody needed another MP3 player. These products existed because someone had a conviction about what should exist and the stubbornness to make it real.
I'm not comparing my pub guide to the iPhone. Obviously. But the principle scales down. When you build from genuine personal need, you skip a step that most product teams spend months on: understanding the problem. You already understand it. You live it. You feel the friction every single day.
You're your best user
Little London exists because I was tired of rubbish Saturday mornings. Every weekend, the same conversation with my partner: "What shall we do with our son today?" Followed by thirty minutes of scrolling through outdated blog posts, paywalled listings, and recommendation sites clearly written by someone without a kid. The information existed somewhere, but it was scattered, unreliable, and wrapped in so much noise that finding something good felt like work.
I didn't need to interview parents to understand this problem. I didn't need to survey my target audience. I AM my target audience. I know exactly what's frustrating about finding weekend activities for a kid in London because I experience that frustration in real time, repeatedly, with increasing irritation.
That's the advantage of building for yourself. You skip the translation gap entirely. There's no research phase where you try to understand someone else's pain. There's no empathy exercise where you imagine what it might be like to have this problem. You have the problem. You know what a solution should feel like because you know what the absence of a solution feels like. Every design decision gets filtered through your own experience, which is the most reliable data source you'll ever have.
The same is true for every project I have built. London Pub Guide came from wanting a recommendation I could trust, not a TripAdvisor ranking gamed by paid reviews. Forest Quiz came from a lifetime of caring deeply about Nottingham Forest and wanting a better way to test and share that knowledge. EVERYWEAR came from being genuinely interested in wearable technology and frustrated by how fragmented the news coverage was.
The portfolio effect
Here's the thing that the validation obsessives miss: even when a project doesn't find a massive audience, it still works. Not as a business, necessarily. But as proof.
Proof that you can ship. Proof that you can take an idea from nothing to something real. Proof that you have taste, that you can make decisions, that you can see something through from concept to live product. In a world where most people talk about what they would build if they had the time, the resources, the team, the budget - actually building things is a profound differentiator.
Each project teaches you something the previous one didn't. Little London taught me about content organisation at scale. Forest Quiz taught me about engagement mechanics. CultureTerminal taught me about automated content pipelines. EVERYWEAR taught me about niche audience curation. The learning compounds. The skills stack. And the portfolio grows into something that says more about your capabilities than any CV ever could.
When someone looks at fourteen live projects, they don't see fourteen separate things. They see a pattern. They see someone who has ideas and executes on them. Someone who ships. Someone who doesn't wait for conditions to be perfect before starting. That pattern is worth more than any individual project's traffic numbers.
The permission trap
I spent fifteen years in advertising agencies. Good ones - independent, creative shops where the work mattered and the people were talented. But even in the best agencies, there's a permission structure that governs everything. You need the client to approve the brief. You need the creative director to sign off on the concept. You need the account team to agree on timing. You need budget approval. You need legal review. You need stakeholder alignment.
By the time something makes it through that gauntlet, the sharp edges have been sanded off. The risky idea has been de-risked. The bold choice has been moderated. The thing that arrives in the world is rarely the thing that was originally imagined. It's a negotiated compromise - better than nothing, but less than it could have been.
Building your own things removes every gate. Every single one. The only person you need to convince is yourself. The only sign-off required is your own judgment. The only timeline is however long it takes you to get it done. There's no brief to write, no pitch to prepare, no committee to persuade.
This sounds like freedom, and it is. But it's also terrifying, because there's nobody to blame when it doesn't work. No client who watered down the idea. No budget constraint that forced a compromise. No team member who dropped the ball. If the product isn't good, it's because your taste wasn't good enough, your vision wasn't clear enough, or your execution wasn't sharp enough. That level of accountability is uncomfortable. It's also the fastest way to get better.
Every project I ship makes the next one better. Not because the tools improve - though they do - but because my judgment improves. I learn what matters and what doesn't. I learn where to spend time and where to move fast. I learn the difference between a detail that elevates the whole product and a detail that nobody will ever notice. That learning only happens when you own the entire process, from idea to live product, with nobody to hide behind.
So here's my advice, for whatever it's worth: build things nobody asked for. Build the app you wish existed. Build the guide you could never find. Build the tool that solves your specific, personal, possibly niche problem. Don't wait for validation. Don't wait for permission. Don't wait for someone to tell you it's a good idea.
The world has enough committee-approved, focus-grouped, A/B tested products. What it needs is more things built with conviction by people with taste. Products that exist because someone cared enough to make them, not because a spreadsheet said they should.
Build it. Ship it. See what happens. The worst case scenario is that you learn something. The best case scenario is that you create something that matters - to you, and maybe to other people too. Either way, you'll have built something real. And in a world full of people who only talk about what they would build, that puts you in a very small, very interesting minority.
