Fourteen products in under a year. Not all of them good. Not all of them successful by any conventional metric. But all of them live, all of them working, and all of them teaching me something the previous one didn't. Here are the patterns, mistakes, and non-obvious lessons from building more products than most people ship in a decade.
1. Naming matters more than you think
I learned this the hard way. A product's name is its first impression, its elevator pitch, and its brand identity rolled into a single word or phrase. Get it right and people understand the product before they've seen it. Get it wrong and you spend forever explaining what it is.
Modern Retro works because the name IS the concept -- modern brands, retro aesthetic. CultureTerminal works because it sounds like what it is: a hub for culture. Little London works because it immediately communicates the scale (a small kid) and the place (London). The names I've struggled with are the ones that sound clever but don't communicate. A name should be a window, not a puzzle.
2. The first three are learning
Products one through three were not good. They functioned. They existed. But they lacked the clarity and taste that the later products have. And that's fine. Those first three taught me how to work with Claude Code, how to structure a project, how to think about deployment, and most importantly, how to know when something is ready to ship versus when it needs more work.
If I'd treated product one as the thing that had to be perfect, I'd still be on product one. The only way to get to product fourteen -- where the instincts are sharper and the output is genuinely good -- was to build through products one, two, and three, accepting they wouldn't be my best work.
3. Scope creep is the real enemy
Not bad ideas. Not technical limitations. Not lack of time. Scope creep. The relentless, seductive expansion of what a product should do. Every single project I've built has been attacked by scope creep, and the ones that survived it best are the ones where I was most disciplined about saying no.
The Forest Quiz is a quiz about Nottingham Forest. It's not a Forest news aggregator, a historical archive, a fan community, or a statistics dashboard. It's a quiz. That focus is what makes it work. The moment I started thinking "what if it also..." was the moment it started to lose its way. I've learned to treat "what if it also" as a warning sign, not an inspiration.
4. Ugly problems are more interesting than pretty ones
The products I'm most proud of didn't come from elegant ideas. They came from messy, unglamorous frustrations. "I can't find anything good to do with my kid this weekend." "I don't know which pub to go to." "I can't keep up with culture news." These aren't beautiful problems. They're annoying ones. And annoying problems make the best products because the motivation to solve them is visceral and renewable.
The pretty problems -- "I want to create a taste-mapping platform" -- are intellectually interesting but harder to sustain. You need the ugly motivation of genuine frustration to push through the difficult middle of a project, when it's half-built and not working properly and you're questioning everything.
5. The product you're proudest of is never the one that gets the most attention
This one still stings a bit. Modern Retro -- my creative flagship, the project that best represents my taste and vision -- gets consistent attention because the concept is visually striking and easy to share. But the project I'm most personally proud of is Trove, the taste engine that maps your interests and finds patterns in what you save. It's more ambitious, more technically interesting, and more personally meaningful. But it's harder to explain in a screenshot, so it gets a fraction of the attention.
The lesson: impact and pride don't always correlate. Build for both, but understand that the project the world loves and the project that matters most to you might be different products. That's not a failure. That's just how attention works.
6. Ship on Saturday
This isn't a productivity hack. It's a mindset. Weekends are when I do my best building because there are no distractions, no emails, no obligations pulling me in different directions. But more importantly, shipping on Saturday creates momentum for the next week. You start Monday with a live product, not an unfinished project. That psychological shift matters more than any time management technique.
7. Everything compounds
Product one taught me how to use Claude Code. Product three taught me about deployment. Product five taught me about design systems. Product eight taught me about content pipelines. Product twelve taught me about automation. Each lesson built on the previous ones. By product fourteen, I was making decisions in minutes that would have taken me hours at the beginning, not because the decisions were easier but because my judgement was better.
This compounding effect is the strongest argument for building lots of things rather than one perfect thing. You learn more from fourteen imperfect products than from one flawless one. The breadth of experience -- different audiences, different problems, different design challenges -- creates a general-purpose product sense that you can't get any other way.
8. The portfolio is the product
Individual projects come and go. Some get traction, some don't. Some I'm proud of, some I'd rebuild from scratch if I had the time. But the portfolio -- the body of work taken as a whole -- is the thing that matters most. It's the pattern that tells a story. It says: this person ships. This person has range. This person can go from a parenting directory to a crypto gallery to a culture aggregator and make each one feel considered.
That range is the unfair advantage. Most builders go deep on one thing. They build one product and iterate for years. That's a valid approach. But building many things develops a different kind of intelligence -- a pattern recognition that spans categories, audiences, and problem types. You start to see the universal principles that make products work, regardless of what the product actually does.
Fourteen products isn't a number I'm trying to grow for its own sake. It's a body of evidence. Evidence that I can ship, that I have taste, that I can solve problems across different domains. The playbook isn't a formula for productivity. It's a pattern of learning that only reveals itself through the act of building, repeatedly, with intention.
Number fifteen is already in my head. The playbook continues.
