Build in public: a practical guide to sharing the real work.
Building in public works when it is a record, not a highlight reel. What to share, what to keep private, how often to post, and the rules that keep it honest when the numbers are small.
For which of you, desiring to build a tower, does not first sit down and count the cost, whether he has enough to complete it?Luke 14:28
Building in public means sharing the work while it is still being done — the decisions, the numbers, the mistakes, the quiet weeks — rather than only announcing the finished result. Done well, it builds trust, attracts the right early people, and forces clearer thinking. Done badly, it becomes a stream of manufactured momentum that nobody believes, including the person posting it.
The difference is almost entirely about rules you set in advance. This site is itself a public build log: SIX33 is being built from zero with the record kept here, under four rules written before there was anything to show. The current verified impact is zero, and the log says so. That constraint is what makes the rest of it readable.
This guide covers why to build in public, what to share and what to protect, how often to post, how to handle the stretches where nothing happens, and how to keep the record honest when growth eventually makes exaggeration tempting.
1. Know why you are doing it.
There are three good reasons to build in public, and they lead to different habits. Accountability: writing the plan down publicly makes it harder to quietly abandon. Learning: explaining a decision to strangers exposes weak reasoning faster than thinking alone. Trust: people who watched the work happen are more likely to believe the result than people who only saw the launch.
Distribution is a fourth reason and a real one, but it is the one most likely to corrupt the record. If reach becomes the main goal, posts drift toward whatever performs, and the honest updates — the boring and disappointing ones — stop getting written.
2. Write your rules before you have anything to show.
The cheapest moment to commit to honesty is when there is nothing to protect. Write a short set of rules and publish them before the first real numbers arrive. SIX33's four are a usable starting point: real numbers or no numbers; failures at the same size as the wins; no fake momentum; keep it readable by someone who does not care about your industry.
Rules written after success tend to protect the available win. Rules written at zero cost nothing to keep, and they give readers a standard to hold you to.
3. Decide what to share — and what to protect.
Share the things that help a reader understand and trust the work: the problem you are solving, the decisions you made and why, real numbers with their dates, experiments and their results, mistakes and what you changed, and what you are deliberately not doing.
Protect anything that belongs to other people or would cause harm: customer and user data, other people's stories without consent, partners' confidential terms, security details, and anything you would not want a competitor or a bad actor to have. Building in public is about your work, not about exposing the people it serves.
Share: decisions, dated numbers, experiments, failures, costs where comfortable.
Share: what you are not doing, and why.
Protect: personal data, other people's stories, confidential terms, security.
Protect: your own wellbeing — you do not owe the internet every hard day.
4. Post on events, not on a schedule — and log the quiet weeks.
A fixed posting schedule pushes you to invent news. Post when something real happens: a decision, a result, a change of plan. Then add one deliberate exception — when a stretch goes by with nothing to report, say so. A short “nothing shipped publicly in eleven days, here is why” is one of the most credible posts a build log can contain, because it proves the log is not curated.
A simple status page that says what you are doing now, and what you are not doing, removes most of the pressure to post for the sake of posting.
5. Share numbers without turning them into hype.
Numbers are what make a public build log useful, and they are where most of them go wrong. Always attach a date and a definition. Say what kind of number it is — reach, delivery, use, return, or change. Never round a small number into a vague large one, and never describe attention as impact.
Expect the temptation to grow with the numbers. The first time a metric looks good, there is pressure to frame it generously. The rules you wrote at zero are what hold the line.
6. Make the record findable and easy to quote.
A build log nobody can find is a private diary. Give it a stable home you control rather than only a social feed: dated entries at permanent URLs, an RSS feed, and a short page that states the current facts for anyone — or any search or AI system — that wants to describe the work accurately. Make it easy to start at the beginning.
Social posts can point to the record. The record should not live only inside the posts.
The short versionWrite the rules at zero, share decisions and dated numbers, protect other people, post on events and log the quiet weeks, and keep the record somewhere you control. A build log is worth reading only if it would also publish the bad month.
Direct answers
Questions about building in public.
What does building in public mean?
Building in public means openly sharing the process of building a product, brand or organisation — decisions, numbers, mistakes and progress — while the work is happening, rather than only announcing finished results.
Is building in public a good idea?
It works well when the goal is accountability, learning and trust, and when you set rules about honesty and privacy in advance. It works poorly when it becomes a performance optimised for reach, because the honest updates stop getting written.
What should you not share when building in public?
Do not share personal data about customers or users, other people's stories without consent, confidential partner terms, security details, or anything that could harm the people your work serves.
How often should you post when building in public?
Post when something real happens rather than on a fixed schedule, and deliberately log stretches where nothing happened. A schedule pushes you to invent news; an event-driven log stays credible.
How do you build in public when your numbers are small?
Publish them anyway, with dates and definitions. Small honest numbers build more trust than vague large ones, set a baseline for later growth, and show readers your standards before success makes them harder to keep.
