For most of my career, I built things behind closed doors. That is how it works in corporate analytics and agency work. You do the job, you deliver it, and the client or employer owns the story. Nobody outside the room knows what you made.
When I started building my own products, I kept that habit for a while. I would work on something quietly, wait until it felt finished and then try to tell people about it. The problem is that "finished" kept moving, and when I finally did share, I was talking to nobody.
So I changed how I work. I share what I am building while I build it. Here is why, what it has done for me and how I try to keep it useful.
What building in public means to me
It does not mean posting every thought or every metric. For me it means:
- Saying what I am working on and why.
- Showing work in progress, including rough versions.
- Sharing what I learned, especially from mistakes.
- Asking for feedback before I have locked anything in.
It is closer to keeping an open notebook than running a marketing campaign.
Why I started
A few reasons, and they are not complicated.
I needed accountability
I have a full-time job, consulting clients and a family. My own products get the hours that are left. When nobody knows what you are working on, it is very easy to let a project slide for a month. When you have said out loud that you are shipping a feature this week, you tend to ship it.
I was tired of guessing
Twenty years in analytics and conversion work taught me that what people say they want and what they actually do are often different. Building in private meant I was guessing about both. Showing work early meant real people could react before I had invested weeks in the wrong direction.
I wanted to teach
I have taught digital marketing at universities, and I train teams at work. Teaching is how I make sense of what I know. Writing up what I am building forces me to understand it well enough to explain it. That has made me a better builder.
What it tends to do
I want to be careful here. I am not going to give you a story about one post that changed everything. That is not how it works for most people, and it is not how it has worked for me. What I can tell you is what building in public tends to do over time.
It builds an audience before you need one
The hardest part of launching is having someone to launch to. When you share along the way, the people who follow your work already understand the product by the time it is ready. Launch day becomes an update to people who care, instead of an announcement to strangers.
It brings better feedback, earlier
When I share a rough screen or a pricing idea, I get reactions I would never get from my own head. Some are wrong, some are noise, and a few are exactly what I needed to hear. The earlier those arrive, the cheaper they are to act on.
It creates proof of work
Anyone can say they build software with AI and no-code. A visible record of real projects, real problems and real fixes is different. It shows people how I think, which matters for consulting and teaching as much as for selling a product.
It connects you with other builders
Sharing openly tends to attract people working on similar problems. That leads to swapped tips, honest feedback and sometimes collaboration. For a solo founder, that community is worth a lot. It is also part of why NoCode Outlaws exists at all.
It makes the work more honest
When you know you will explain your decisions, you make fewer lazy ones. I think harder about security, pricing and scope because I know I will be writing about them.
What it costs
It is not free, and I do not want to pretend it is.
- Time. Writing and posting takes hours I could spend building. I keep it lean so it does not take over.
- Exposure. Sharing something that does not work is uncomfortable. People will see you get things wrong.
- Distraction. It is easy to start building for reactions instead of for users. I have to watch for that.
- Copycats. Someone could copy an idea. In my experience, ideas are cheap and execution is the hard part, so this worries me less than it used to.
How I do it
Here is my actual approach, in case it helps you start.
- Share the problem first. Before I show a product, I talk about the problem it solves and who has it. That attracts the right people and tests whether the problem is real.
- Post work in progress on a rhythm. Not daily. A steady pace I can keep up alongside everything else.
- Show the thing. A screenshot or short recording beats a paragraph of description.
- Share the lesson, not just the update. "I added team invites" is an update. "Here is the row level security mistake I almost shipped with team invites" is useful to someone else.
- Ask one clear question. When I want feedback, I ask something specific, like which of two layouts makes the price clearer.
- Reply to people. The conversation is the point.
What I keep private
Building in public has limits, and setting them early makes it easier to keep going.
- Client work stays confidential. I never share details about employer or consulting projects.
- Customer data and anything that could identify a user stays private.
- Security details that could help someone attack an app stay private until they are fixed, and sometimes after.
- Personal finances I share only in general terms, if at all.
Should you build in public?
Not everyone needs to, and not every project fits. If you are building something in a sensitive space, or you know constant sharing would drain you, a quieter approach is fine.
But if you are a solo founder with no audience and you are waiting until it is perfect to tell anyone, I would push you to try it for a month. Share what you are building, what is hard and what you learned. Keep it honest. See who shows up.
The Crew membership is where our builders share progress with each other each week, if you want a smaller room to start in.
What would have made it better?