Building in Public: Share Decisions Your Customers Can Use

Building in public can make your work easier to understand. Its value depends on what a reader learns from it, not how much private information you reveal.

A useful update connects a decision to the problem it addresses. “Shipped dark mode” may be enough for users waiting for it. A longer post needs a reason to exist: the accessibility consideration, the design tradeoff or the feedback that changed the implementation.

Choose whose understanding you want to improve

Other builders may enjoy a technical breakdown that buyers do not need. Prospective customers may care about a workflow change while investors want different evidence. Choose the reader for each piece rather than trying to satisfy all three at once.

For a fictional appointment-booking product, a customer-facing update could explain why cancelled appointments remain visible to staff. A developer-facing piece could explain how the system distinguishes a cancellation from a failed request. Both use the same work, but answer different questions.

Keep a decision record while you work

Capture four short notes:

• What problem prompted the change?
• Which alternatives did you consider?
• Why did you choose this option?
• What would make you reconsider?

This provides better raw material than asking an AI assistant to invent an inspiring founder story after the fact. Save the source or observation behind each claim, and mark material that is unsuitable for publication.

Write an update with a useful tradeoff

Here is a fictional example:

We kept cancelled appointments in the staff view rather than removing them. A blank slot tells you when someone is free; it doesn't explain whether a customer cancelled or the booking never existed.

The tradeoff is a busier schedule. We're testing a filter so staff can hide cancelled entries while keeping a way to inspect the history. If your team shares a calendar, check whether removing an event also removes context someone else needs.

This offers a decision the reader can apply. It does not require a revenue screenshot, personal crisis or claim that the design already improved retention.

Share results with their boundaries

If you publish a metric, include what you counted, the period and the comparison. Separate signups from active users, revenue from profit and observed change from its possible causes.

When results are not ready, say what you are testing. A plan to measure something is not evidence that the change worked. Avoid filling the gap with “users love it” unless you have appropriate support for that statement.

Make the next update answer a real follow-up

A series can progress from problem to decision to observation. Each post should still make sense to someone who missed the earlier ones. Link back where context matters; do not withhold the useful answer merely to manufacture suspense.

Stop or change the series if it mainly attracts an audience unrelated to your goal, consumes too much working time, or pressures you to disclose things you would prefer to keep private. The narrative guide explains how to connect posts; the solo-founder routine helps fit them into available time.