Should You Build Your MVP in Public?

# Should You Build Your MVP in Public?

Building in public means sharing the process of building your product with an audience as it happens: progress updates, setbacks, metrics, and decisions. The case for it is that it builds an audience before the product launches and creates accountability that forces consistent progress. The case against it is that it costs significant time, attracts feedback from people who are not your customers, and can create pressure to optimize for audience approval rather than product quality.

What you need to know

• Building in public works best for founders who already have an audience or are building one in the same market as their product
• The "build in public" approach generates the most value when what you are building is itself relevant to the audience watching the build
• Public progress can be used by competitors to understand your roadmap and timing
• The accountability benefit is real but can be replicated with private accountability (investors, advisors, a peer group) without the public overhead
• Most successful "build in public" examples are developer tools or creator tools where the builder is also the target customer

The core argument

The best builds in public I have seen are ones where the builder is building for themselves and the audience is a by-product, not a goal. A developer building a developer tool and sharing the technical decisions along the way creates genuine value for other developers who are the target customers. The audience growth is a consequence of useful content, not the goal.

The worst builds in public are ones where the founder is performing the build rather than executing it. Every decision becomes a thread. Every setback becomes a story about resilience. The founder is spending 30% of their time on content about the product instead of the product. The audience grows, the product does not ship, and at some point the founder has to choose between the content machine and the actual work.

My read on the Nexli build was that public documentation would have slowed the timeline. School management systems are not inherently interesting to a general audience. The decisions I was making about multi-tenant architecture, role-based access control, and the attendance system were technical problems with specific right answers. Publishing the process would have attracted opinions from people who had never built a multi-tenant SaaS, would have invited scope suggestions from non-customers, and would have added content overhead to a build that was already competing with my class 12 coursework.

Building in public makes sense for certain founders. If your product is in the creator tools, developer tools, or startup tools space, your target customer is probably already on Twitter or LinkedIn watching these builds. If your founder story is genuinely compelling and relevant to your market, the audience becomes a distribution channel. If you have enough time to both build and document without one cannibalizing the other, it is worth trying. For everyone else, build privately, ship publicly, document retrospectively.

Common mistakes

1. Sharing every setback for emotional resonance. Setback content performs well on social media. It also signals instability to potential customers and investors who find your content before your product.

1. Treating audience growth as product validation. Getting 2,000 Twitter followers interested in your build does not mean 2,000 people will pay for the product. These are different behaviors.

1. Publishing the roadmap in detail. If you share your feature roadmap publicly, you are sharing it with every competitor in your market. Discussing direction and philosophy is fine; specific features and timelines are not.

1. Letting audience feedback drive product decisions. The audience watching you build is not randomly sampled from your target market. They skew toward other founders and developers. Building what they suggest is building for the wrong people.

1. Starting the build-in-public content before there is anything real to show. Announcing that you are building something before you have a working prototype is a common pattern. It generates early engagement and creates pressure to follow through before you have enough information to know if the thing is worth building.

Where to start

1. Define what your build-in-public goal actually is. Audience building? Accountability? Customer discovery? Each goal suggests a different cadence and type of content. Mixing them without clarity produces unfocused content that serves none.

1. Set a time budget. How many hours per week can you spend on content without it cannibalizing the build? That number is your ceiling. If the answer is zero right now, build privately and publish retrospectively.

1. Test with one platform first. Pick one channel (Twitter, LinkedIn, or a newsletter). Commit to a consistent cadence for 8 weeks. Measure whether the content is generating conversations with potential customers, not just engagement from other builders.

Related reading

• Pre Launch Wait Lists: Do They Work or Are They Theater?
• The MVP Postmortem: Questions to Ask Yourself Six Months In
• Building an Engineering Blog That Lands Jobs and Clients
• Building a Personal Brand as an Engineer Without Becoming an Influencer