Building in public without turning it into a second job

Why it works, and why it fails

Building in public works because it does two things nothing else does as cheaply. It creates a feedback loop: people tell you what is confusing, what is missing, and what they would pay for, while you can still change it. And it creates trust: by the time you ask someone to install the thing, they have watched you build it, fix it, and say honestly when it broke.

It fails when the posting becomes the product. You start optimizing for the update instead of the work the update is about. The calendar fills, the building slows, and the audience can tell. A feed of polished progress reports from a project that is not progressing is worse than silence, because it spends the trust you were trying to earn.

The fix is not to post less. It is to make the posting a byproduct of the building, so it costs almost nothing and cannot get ahead of the work. Four habits do that.

Capture raw updates while building

The draft of every update already exists. It is in your commit messages, your session notes, the message you sent a collaborator when the bug finally made sense. The mistake is throwing those away and sitting down later to "write an update" from memory, which is slow, and which produces the polished, bloodless version.

Instead, keep a running log as you work. One file per day, a line or two each time something happens worth knowing: what you tried, what broke, what you decided and why. We do this across every project, partly for building in public and mostly because it is the only way the next session, human or agent, knows what the last one learned. The log is not for an audience. It is raw, specific, and sometimes wrong, which is exactly what makes it a good source.

At the end of a work block, the update is a matter of reading the log and picking the two lines that would be interesting to someone who was not there. That takes five minutes, not an evening.

Repurpose once, not endlessly

One finding, several surfaces, one pass. A field note on the product site is the long form: what we tried, what we learned, what changed. The same finding becomes a short post on whichever network your users are on, cut to the single most useful sentence and a link. If there is a diagram or a screenshot, it goes in both. That is the whole chain.

Two rules keep this from becoming a treadmill. First, the long form is written once and is the only thing that gets real editing time. Everything downstream is a cut, not a rewrite. Second, you do not post everywhere. Pick the one or two places your actual users read and ignore the rest, however loud the advice to be everywhere. A good post on one network beats a thin one on five.

Keep a rolling two-week calendar

Not a content calendar with slots to fill. A rolling list of the things that are going to happen in the next two weeks that would be worth telling someone about: a release, a migration, a decision between two approaches, a result from an experiment. Each one is a future update you already know the shape of.

Two weeks because that is as far as a small team can honestly see. Rolling because every week something lands, something slips, and something new appears, and the list should reflect that rather than pretend to a plan. When a week has nothing on it, that is information too: either the work is in a quiet stretch, in which case say nothing, or the work has stalled, in which case the calendar just told you before the audience did.

The list lives next to the work, in the same tracker or the same repo, not in a separate marketing tool. If updating it is a context switch, it will not get updated.

Ship first, post second

This is the rule that keeps everything else honest. The update goes out after the thing is live, not before, and not instead. A release note is written when the build is approved. A launch post is written when the product is in the store. A "we're working on X" post is allowed exactly once per X, and only if X ships within the two-week window on the calendar.

It feels slower. It is not. Pre-announcing creates a debt that every subsequent update has to service, and it turns the audience into a deadline. Posting after means every update is a fact, the audience learns that your updates are facts, and the day you say "this is live" they believe you and go install it.

It also means that when something slips, you do not have to post about the slip. You just post when it lands. The silence in between is not a failure of building in public. It is building.

What this looks like for us

Every product we run has a field notes page on its own site. The posts are written from the daily logs, after the work ships, and they say what broke as readily as what worked. The company site carries the cross-product notes, like this one. Launch posts go out the day the product is live, not the week before. When we have nothing to say, we say nothing, and nobody has ever complained about the gap.

Total time per week: an hour, most of it the long-form note. The log costs nothing because we would keep it anyway. The calendar is a list in the same place as the tasks. The repurposing is a cut. The posting is a paste. No second job.

If you are building something and want to talk through how to show the work without it eating the work, we are easy to find.