Build in Public for SaaS

The indie hacker internet sells building in public as a universal growth strategy. It is not. It is a specific distribution tactic that works well for a specific kind of company at a specific stage, and it carries real costs that nobody putting an MRR chart on X talks about. Here is where the line sits, and how to know which side of it you are on.

What are the four things people mean by building in public?

They get bundled together and they have completely different risk profiles. Separating them is the most useful thing you can do before deciding anything.

Most of the benefit sits in the bottom two rows and most of the risk sits in the top one. Founders who want the audience-building effect of transparency without the exposure should write about decisions and ship publicly, and leave the revenue dashboard alone.

Who does this actually work for?

Three preconditions, and you need all three. Missing any one of them turns building in public into unpaid content production for an audience that will never buy.

Your buyer is a builder. Developers, indie founders, marketers who like process. These audiences find how-you-work content intrinsically interesting. A hospital procurement officer does not. This is why the pattern flourished at Plausible, PostHog and Supabase and is essentially absent in vertical SaaS.

Your category is already understood. Transparency amplifies attention, it does not create category comprehension. If people need educating on why the problem exists, you need explanatory content first. Building in public is a distribution multiplier on an existing message, not a substitute for one.

The founder is willing to be the channel. This is personal and non-delegable. A ghostwritten build-in-public account is obvious within three posts and does more damage than silence. If the founder does not want to write, pick a different tactic. The founder-led LinkedIn playbook and the X for B2B SaaS guide cover the mechanics once you have decided the founder is in.

What are the risks nobody in the indie hacker threads mentions?

Four, and the third one is the one that actually ends programmes.

Competitive intelligence, mostly about sequencing. Competitors already see your pricing page, your changelog and your job ads. What a public roadmap adds is timing. If a funded competitor knows you will ship SSO in Q3, they can announce theirs in Q2 and take the deals you were counting on. Ship logs are safe. Forward-looking roadmaps with dates are not.

Enterprise buyer perception. Procurement and security teams research vendor viability, and they will find your dashboard. A number that reads as healthy growth to your Twitter audience reads as a going-concern risk to a director signing a three-year contract. This is not hypothetical. Founders moving upmarket consistently report taking metrics pages down before their first six-figure deal, and that is the right sequence.

The credibility trap. You publish growth for eighteen months. Then a quarter goes flat, or churn spikes, or a big customer leaves. Now you must publish that, and publishing it will hurt, or you go quiet, and the silence is read correctly as bad news. There is no third option, and everyone who has run open metrics for more than two years has faced it.

Investor and acquirer complications. Public financials narrow your room to manage a fundraise or acquisition narrative. Diligence teams will read your archive, and any gap between what you published and what is in the data room becomes a question you have to answer. Not fatal, but it costs time and influence at exactly the wrong moment.

What should you share and what should you hold back?

Share freely	Share carefully	Hold back
Shipping log and changelog	Revenue, if you will publish bad quarters	Named customer details without permission
Decisions and the reasoning behind them	Churn rate and reasons	Forward roadmap with dates
Failures and what you changed	Pricing experiments after they conclude	Security incidents before remediation and disclosure
Engineering and design process	Headcount and hiring plans	Individual employee performance or departures
Customer problems, anonymised	Fundraising status, once announced	Deal-specific competitive intelligence
Your point of view on the category	Traffic and conversion data	Anything covered by a customer NDA

The middle column is where judgement lives. Churn is a good example: publishing your churn rate is genuinely useful to your audience and genuinely dangerous in a competitive deal, where a rival can quote it back to your prospect out of context. Publish it as a trend with explanation attached, or not at all.

How does this interact with community and social?

Building in public is a content strategy that needs somewhere to land. On its own, posts into an empty feed do nothing. The companies where it works have a community underneath it: a Slack, a Discord, a subreddit, an issue tracker where people already talk.

PostHog and Supabase are instructive because their public roadmaps are functionally community infrastructure. Users file issues, vote, and see their requests move. The marketing benefit is a byproduct of a product process that genuinely uses public input. Copying the output without the input loop gives you a roadmap page nobody reads and a set of commitments you now have to honour. The mechanics of building the underlying loop are in community-led growth for B2B SaaS.

On measurement, be careful. The follower counts and impression numbers this tactic produces are exactly the figures that look impressive on a slide and mean nothing. Judge it on signups attributable to the founder’s audience, demo requests that mention a post, and hiring pipeline, which is frequently the largest real return. The SaaS social media ROI calculator is the fastest way to work out whether the founder’s hours are worth more here or somewhere else, and the honest framing for the board is set out in board reporting for SaaS CMOs.

What does the exit look like?

Plan it before you start. This is the part nobody writes about and it is where most build-in-public programmes end badly.

What I would actually recommend

Share process and decisions freely, at any stage, in any category. The downside is close to zero and it compounds into something genuinely valuable: a reputation for thinking clearly in public, which is the thing that makes people take your calls.

Share revenue only if two things are true. You can stomach publishing a bad quarter, and your buyer does not evaluate vendor stability as part of procurement. For most indie and small developer-tool businesses, both hold. For most B2B SaaS above $2M ARR selling to companies with a security questionnaire, at least one does not.

Stop publishing metrics before you sell six-figure contracts. Not after the first awkward procurement conversation. Before. The transition costs you a small amount of audience goodwill and saves you a category of deal friction that is very hard to argue your way out of once it starts.

And keep the roadmap vague about dates even when you keep it public. Shipping logs build trust. Forward commitments build a stick your competitors and your customers will both use on you.

Where to go from here

If you are early and your audience is technical, start with a weekly shipping post and one decision explained. Give it a quarter. Measure signups and hiring pipeline, not followers, and read vanity metrics in SaaS marketing before you build the dashboard.

If you are already publishing metrics and moving upmarket, write the exit trigger down this week. The broader question of how this fits alongside paid and organic channels is covered across the social media marketing for SaaS hub, and the measurement side connects to everything in SaaS metrics and analytics. The underlying dynamic, that the person and not the company carries the distribution, is what founder-led marketing describes.