Building in public is sharing the process of building a company, product, or feature in real time, including the metrics, failures, and decisions that most founders keep private. It works as a marketing strategy because it creates genuine interest from people who are building similar things, and it compounds: the audience you build by sharing your process becomes the community that recommends your product. The founders who have done this most effectively, Pieter Levels, Jon Yongfook, Arvid Kahl, the PostHog team, have built significant audiences not by sharing wins, but by sharing the specific details of how they navigate difficult decisions.
I have been building in public for Pristren since early 2025. Here is what has worked and what has not.
What to Share
Metrics, with context. Monthly revenue, user counts, churn rate, paid conversion rate. The context matters as much as the number. "We hit $5k MRR this month, up from $2.8k. The growth came almost entirely from the time tracking feature launch, which drove 40 new paid conversions in 30 days" is more valuable and more interesting than "we hit $5k MRR."
Product decisions and the reasoning behind them. "We decided not to build native mobile apps in 2026. Here is why: 80% of our users are on desktop, mobile web works for the other 20%, and the engineering cost of a native app would be 40% of our engineering capacity for 12 months. We will revisit when we have more resources." This kind of decision transparency is uncommon and valuable. People building similar companies want to know how you think through decisions.
Failures and what you learned. The building-in-public content that performs best is often failure content. "We launched a feature that three enterprise customers specifically asked for. Zero of them used it after launch. Here is what we got wrong." Real failures, shared with specific analysis, are some of the most-read and most-cited posts I have published.
The process of building specific features. "How we built async AI meeting summaries in 3 days" with the actual technical decisions, trade-offs, and dead ends along the way. This is interesting both to developers (who relate to the technical experience) and to potential customers (who understand what went into the product they are using).
Launches and responses. Share the process and results of major launches. Product Hunt day metrics, Show HN response, first 30 days of a new feature. The numbers, what worked, what you would do differently.
What Not to Share
Customer data or identifying information. Never share customer names, revenue breakdowns that would identify customers, or specific customer feedback without explicit permission. This is both an ethical and practical concern: customers who discover you shared their details will leave.
Employee information. Do not share salary details, performance issues, or internal conflicts that involve named employees. Team members have privacy interests that outweigh the marketing value.
Strategic plans before execution. If you are planning to enter a new market, build a major feature, or partner with a specific company, sharing that plan publicly before it is executed exposes you to fast-followers and can tip off competitors.
Financials that create false impressions. Sharing revenue without context can mislead: "$50k MRR" sounds impressive until you mention $80k in operating costs. If you share revenue, share the relevant context. If you are not profitable, do not imply you are.
Information shared in confidence. If an investor, advisor, or customer shared something with you under implicit or explicit confidentiality, sharing it publicly is a trust violation.
