Build in public with AI
How I plan, design, build and sell products with AI, and show every step: the thinking, the files, the mistakes. One video, one article and the working files per build, and several products at once instead of one startup's diary.
What build in public means, and what I do differently
Build in public usually means a founder documents one company from the first idea to the first customers: the numbers, the launches, the setbacks, in the open. Indie Hackers and X are full of it, and it works because people trust a process they can watch.
I do it slightly differently. I build several products at once, and the product is rarely the point. The point is the method: how I think through a problem, how I plan it, how I design and develop it with AI, and how I sell it. You get the process I would run on your product.
Since AI, building is not the problem anymore, so I rebuild the tools I used to pay for and run my business on them: a booking tool instead of Calendly, my own invoicing, a scheduler for social posts instead of Buffer, one backend for everything. Each one becomes an episode, with the files that made it.
I call it AI coding to keep it apart from vibe coding. Vibe coding, the way Andrej Karpathy coined it, means you accept whatever the model writes and hope it runs. I read, review and specify. The spec is the product, the code is what the agents produce from it, and it has to hold up in production and in sales.
Where people build in public
Watch mine
The method: plan, design, develop, sell
Plan
What problem, for whom, what does done look like. A user story map and a written spec before any code. This step gets most of the time.
Design
The flows, the screens, the data model. Pixel by pixel where it matters, rough where it does not. The design is the last chance to change my mind cheaply.
Develop with AI
Claude Code builds from the spec, I review, test and correct. AI coding with reviews, so what ships still runs in six months.
Sell
Positioning, the first customers, the funnel. The step most builders skip, and the reason most AI products look the same and sell nothing.
Why I build in public, and why you might
Gaining trust
An audience that watched the process buys the result. Every file I publish is proof that the method works before anyone pays for it.
Faster feedback
A plan published before the first commit gets corrected by readers who tried the same thing. That is cheaper than finding out after launch.
Documenting decisions
Every reversed decision is written down, so the next one is better informed. The journal is my own memory, in public.
Reducing costs
No ad budget, the audience grows with the builds. No research budget, the feedback arrives in the replies. The price is time, and people see the mistakes. I take that trade.
Planning gets 80 percent of the time
Step one of the method gets most of the time, and these three numbers are the reason. The old rule for software was 80/20: most of the effort goes into deciding what to build, the rest into typing it. AI did not flip that rule, it sharpened it.
So I plan like it is 80 percent of the job, because it is: a user story map, a written spec, an architecture sketch, then the build. The build is the short part, and every episode shows how much of the time went into the thinking before it.
15% of a developer day is reading or writing code
Microsoft Research asked 5.971 developers how they spent the previous day: 84 minutes of reading and writing code, 74 of debugging, 41 of testing. The rest was meetings, mail, planning and thinking. AI shrinks the coding minutes. The rest stays with you.
Read the Microsoft study19% slower with AI tools, in a 2025 study
METR measured experienced developers on their own codebases: 19 percent slower with AI tools, while they believed they were 20 percent faster. Faster typing does not fix a wrong decision, it ships it sooner.
Read the METR study99% of the time you are not writing code
That is how Andrej Karpathy, who coined vibe coding, describes the work now: orchestrating agents, reviewing what they produce. What is left for the human is the thinking.
Read the Karpathy postThe outcome of every building session
A YouTube videoI show the result and walk through what happened behind it: the decisions, the dead ends, the fixes. The format moved from watching me type to explaining what I did and why.
The written version in the journal, with the reasoning that does not fit into a video, and the point where the plan met reality.
Every episode ships its working files: the markdown plan, the architecture, the prompts, sometimes the code. You take them and use them on your own product.
Get access to prompts, markdown files, blueprints
Get free access to all files
Get access via magic link 🪄
This creates your free Product Bakery account. Terms and privacy policy apply.
How to start building in public
One question first
Are you building in public for one product, or for everything you build, the way I do? The first is a launch diary, the second is a workshop. Both work, but they change what you post. Decide, then start.
- Step 1
Start today, and start wrong
Open the YouTube channel now and document what you build, in whatever form you have. My first videos recorded every Claude prompt live and cut out the waiting. Later I learned that showing the outcome and the markdown behind it works better. That change only came from publishing the wrong version first. Perfect is the thing that stops you.
- Step 2
One channel is enough
Gary Vee says run ten channels. My advice: one YouTube channel, maintained. Everything else multiplies the work, and nothing multiplies the result. Add a second channel when the first one runs without you thinking about it.
- Step 3
Protect yourself first
Before the first upload: no passwords, no secret domains, no keys on screen. When you show a Claude session, read what it prints before you publish, terminal output leaks things. Customer data never appears, full stop. One conversation with a lawyer, or a long one with an AI about your specific case, is worth the hour.
- Step 4
Find a rhythm you can keep
YouTube loves regularity, you love not being stressed. Daily burns you out, quarterly is a launch post and not build in public. Weekly to every second week works. The test for every piece: would you watch it yourself? I make content I would watch.
- Step 5
Never give up, and stop counting likes
The people who make it failed one more time than the ones who did not. If likes decide your mood, you live in a loop of highs and lows. Do it because you like it and stand behind it, then the numbers stop mattering. I do not have ten million followers, and I keep going. If you do it only to get big, you use the thing instead of serving it, and that never holds.
Build in public FAQ
Vibe coding is a way of working with AI: accept what the model writes, skip the reading, see if it runs. Build in public is a way of publishing: show the work while it happens. You can do both, and most people who vibe code in public ship demos. I do the other pairing, AI coding with specs and reviews, published in the open, so what ships still works six months later.
No. The files are markdown, the videos explain the decisions, and the method (plan, design, develop, sell) is the same whether you write code, prompt an agent or brief a developer. Basic Claude Code knowledge helps for the technical episodes, and the community is where you ask when you get stuck.
Classic examples are founders sharing monthly revenue on X, open roadmaps and public changelogs. In my journal you find 8 builds so far: a business backend, an onboarding questionnaire, an AI watermark cleaner, a one file writing system for Claude and the setup of the journal itself, each with the video and the files. The bigger blueprints live on the map.
It goes into the episode. In the first episode I decided to write my own backend for every automation, because I did not want to depend on Make.com. Two builds later I used Make.com for a small automation, because a backend for a five step workflow is a wasted afternoon. The hypothesis was wrong, the episode shows it, and the next decision was better for it. That moment, when the plan meets the real thing, is the part most build in public accounts skip.
Transparency has edges, and I say where they are. I built a password manager and I do not publish it, because one careless commit with a security hole is worth no episode. Customer names and anything covered by GDPR stay out. Revenue numbers stay out for now. Everything else, the plans, the mistakes, the tools and the files, is on the table.
In the Product Bakery, the founders community behind this page. The voting board decides what I build next, and every second Friday the group meets live with your product on screen.