Building in Public: What I Learned Shipping 18 Products

In 2024, I could not build anything. I had ideas. I had fourteen years of experience in advertising strategy, which meant I was very good at thinking about what should be built, who it should be built for, and why. But the gap between knowing what to build and actually building it was a canyon — one I had stared across my entire career, watching developers and designers do the part I could not. Then I picked up Claude Code. And the canyon closed.

Over the next eighteen months, I built eighteen products. A culture intelligence platform that synthesises fifty news feeds into a daily briefing with AI-generated audio. A brand scoring system that rates twelve hundred brands on cultural relevance using a hybrid of real data and AI. A parenting directory for London. A visual book library. A Japanese learning app. A wearable tech aggregator. A pub guide. A tube exit finder. And more. Eighteen distinct products, each with its own strategy, design system, content, and audience. Shipped. Live. Real.

I did not write a single line of code.

This is the essay about what that journey taught me. Not the technical how — that is straightforward enough that it barely needs explaining. The interesting lessons are about something else entirely: what happens when the bottleneck shifts from execution to judgment, and what that means for who gets to build and why.

What "non-coding" actually means

Let me be precise about what I mean when I say I built products without coding, because there is a misconception that needs correcting. Non-coding does not mean non-working. It does not mean you press a button and a product appears. It does not mean the AI does everything while you watch.

What it means is that the AI handles the syntax — the actual writing of HTML, CSS, JavaScript, Python, whatever the project requires. The human handles everything else. And "everything else" turns out to be an enormous amount of work.

You still need to know what to build. That requires strategic thinking — understanding the problem, the audience, the competitive landscape, and the gap in the market. You still need to make design decisions — colour, typography, layout, spacing, interaction patterns. You still need to write the content — the headlines, the copy, the microcopy, the tone of voice. You still need editorial judgment — what to include, what to cut, what order to present things in. You still need to project-manage the whole thing — sequencing decisions, maintaining coherence, iterating based on what is and is not working.

In other words, you need every skill that goes into building a product except the ability to write the code. You need strategy, taste, editorial judgment, design sense, and the ability to make hundreds of small decisions that collectively determine whether the product is good or not. The AI writes the code. The human does everything that makes the code worth writing.

This is not easier than traditional development. It is different. And the skills it rewards — taste, judgment, editorial sense — are skills that were always valuable but never before sufficient on their own to ship a product.

The "Wait, YOU built this?" moment

There is a reaction I get from people when they see the products and learn that I am not a developer. It is always some version of the same thing: a pause, a slight double-take, and then: "Wait. YOU built this?"

This reaction tells you something important about where we are in the cultural understanding of AI tools. People still associate building with coding. They still assume that if something looks and works like a real product, a real developer must have made it. The idea that a strategy director — someone whose career has been spent thinking rather than making — could ship a real product is still genuinely surprising.

I believe this surprise will fade within three to five years, as AI-assisted building becomes normalised and the "non-coder" category becomes large enough to be unremarkable. But right now, in 2026, the surprise is real and it is a genuine advantage. It signals something that a CV cannot: this person does not just think about what should be built. They build it. They ship it. They make it real.

For anyone in a strategic or creative role, this is the single most powerful proof point you can offer. Not a deck. Not a framework. Not a case study about work done by a team. An actual, live, working product that you conceived, directed, and shipped. In a world full of people who talk about ideas, the person who has made eighteen of them real stands out in a way that no amount of credentials or experience can match.

What worked

Across eighteen products, a few patterns emerged in what worked best.

Speed of shipping matters more than perfection at launch. The products that taught me the most were the ones I shipped fastest. Getting something live — even if imperfect — creates a feedback loop that no amount of planning can substitute. You see it in context. You use it yourself. You share it with people and watch their reactions. The learning comes from being live, not from being polished.

Naming matters enormously. The products that resonated most had names that immediately communicated what they were or sparked curiosity. The Relevance Index. Taste OS. First Out. The Pattern. Each name carries the concept. Each name makes you want to know more. The products where I spent less time on naming consistently underperformed on initial interest, regardless of their quality.

Design coherence is the biggest taste signal. When everything fits together — the name, the visual design, the typography, the tone of voice, the user experience — it creates an impression of quality that goes beyond any individual element. The products that felt most "real" were not the most feature-rich. They were the most coherent. Every decision pointed in the same direction.

Writing is the differentiator. In a landscape full of AI-generated content, human writing — writing with a genuine voice, a real point of view, specific opinions and experiences — stands out more than it ever has. The products where I invested most in the writing were the ones that generated the strongest response. The content is the product. The features are just the frame.

What did not work

The failures were just as instructive.

Building without distribution is building into a void. Several products were good — genuinely good — and got zero traction because I did not put enough energy into telling people they existed. The "build it and they will come" mentality is a fantasy, especially for solo builders without an existing audience. Distribution is not a nice-to-have. It is the entire game.

Feature creep kills coherence. The products that suffered most were the ones where I kept adding features instead of refining the core experience. Every feature you add dilutes the product's clarity. The best products are the ones where I had the discipline to say "this does one thing, and it does it well" and resist the urge to add more.

Not writing about projects is a missed opportunity. Building is half the work. The other half is telling the story of what you built and why. I consistently procrastinated on this — I would ship a product and move on to the next one without writing the case study, the blog post, or the story behind it. Every time, I regretted it. The products that got the most traction were the ones I wrote about. The products I shipped silently disappeared into the noise.

What surprised me

The biggest surprise was how much the skills I built in advertising transferred directly to AI-assisted building. Strategic thinking — the ability to define a problem, identify an audience, and frame a solution — is exactly what you need when deciding what to build. Brand thinking — the ability to create a coherent identity across every touchpoint — is exactly what makes a product feel polished and intentional. Presentation skills — the ability to structure information, create a narrative, and guide someone through a story — are exactly what you need when designing a user experience.

After years of worrying that my skills were too abstract, too strategic, too removed from "real" making, I discovered that they were the exact skills that AI-assisted building rewards. The AI can make anything. The strategy director knows what is worth making. That turned out to be the perfect combination.

The second surprise was how quickly taste becomes the only variable. When every product is built with the same AI tools, the only thing that distinguishes one builder from another is their judgment — what they choose to build, how they choose to design it, what they include and what they leave out. Two people using identical tools will produce wildly different results. The difference is taste. And taste, I discovered, is not something you develop overnight. It is the accumulation of years of looking, reading, experiencing, and forming opinions. My entire career of consuming culture, obsessing over design, and building strategic judgment was, it turned out, training for this moment.

The meta-lesson

Here is the thing that sits underneath everything else I have learned: making things changes you. Not in a soft, inspirational, "journey of self-discovery" way. In a concrete, tangible, professionally transformative way.

Before I started building, I was a strategist. I thought about things. I advised on things. I created presentations about things. After building eighteen products, I am a strategist who ships. The same strategic mind, but now with the ability to execute directly. This is not a subtle difference. It is a fundamental shift in professional identity and professional value.

The market is full of people who think. It is full of people who strategise, who plan, who advise. It is not full of people who do all of that and also build the thing. The compound effect of strategy plus execution is not additive. It is multiplicative. You are not just a strategist who happens to build. You are a new category of professional — someone who understands the problem deeply and can solve it directly.

Where this goes

AI-assisted building is in its earliest stages. The tools I used eighteen months ago are already dramatically less capable than the tools available now. The gap between "what I can imagine" and "what I can build" closes further every month. Within a few years, the tools will be good enough that the execution gap disappears almost entirely. At that point, the only remaining question is: what is worth building?

This is the question I have spent my entire career preparing to answer. Fourteen years of thinking about audiences, brands, culture, and what makes things resonate. Fourteen years of observing, connecting, and forming opinions about what is good and what is not. That preparation did not know it was preparation at the time. It felt like a career in strategy. It turned out to be training for the most important skill in the age of AI: knowing what is worth making.

The tools will keep getting better. They will get so good that building a product will be no more remarkable than writing an email. At that point, everyone will be able to build. The question that separates the builders who matter from the builders who do not will be the same question it has always been, underneath all the technology: does this need to exist? Does it make something better? Is it worth someone's time and attention?

That is not a technical question. It is a taste question. And it is the question I will keep trying to answer, one product at a time.

Eighteen down. The best ones are still ahead.