Build in Public: A Developer's Guide to Growing an Audience

Share work as you build

To build in public, share selected progress on your product: a feature you shipped, a decision you made, or a problem you are still working through.

Choose details that help the people you want to reach. A developer might want the migration steps; a prospective customer might want to see the workflow the feature supports.

Choose where to post

Start with a channel where your intended readers already take part. Read its discussions before deciding what to publish.

Short updates can show a screenshot and a brief explanation. Longer posts can walk through a technical decision or an experiment. Adapt the length and context to each channel.

If your updates start in GitHub, use the GitHub-to-social posting workflow. For tools, read the build-in-public tools guide.

Pick a specific story

A shipped change. Show what someone can now do. Include the steps, availability, and restrictions that matter.

A decision. Explain the options, the constraint, and why you chose one. "We chose PostgreSQL because we needed transactions across these tables" is more useful than announcing a database choice alone.

A lesson. Describe the problem, what you tried, and what you would do differently. Include enough context for another builder to judge whether the lesson applies to them.

A customer outcome. Ask permission before sharing a customer's quote or results. Use their actual words and explain how any numbers were measured.

A business milestone. Share a number only when you can substantiate it and are comfortable making it public. State the period and definition, such as monthly recurring revenue or active users.

Decide what stays private

Get permission before sharing customer details or support conversations. Check screenshots for names, email addresses, credentials, and private repository content.

Wait until a security issue is resolved and disclosure is appropriate before writing about it. Keep internal access details out of examples.

If you are upset about an interaction, draft the post privately and review it later. A public complaint can disclose information or make commitments you did not intend.

Build a routine you can maintain

Pick a cadence that fits your work. Keep a short list of changes and lessons during the week, then choose the ones worth explaining.

Reply to relevant questions and discussions. Pay attention to what people ask after reading your posts; those questions can identify missing context or topics for the next update.

Follower growth varies. Use your own results to decide whether the time spent is worthwhile.

Give interested readers a next step

Link to the relevant feature, release note, or guide. Explain what the reader can do there. A post announcing a feature should say whether it is available now and who can use it.

Measure visits, signups, and customer conversations where you can. A follower count alone does not establish demand or revenue.

Draft one update

Choose a recent change and write a few sentences about the customer task it supports. Add a screenshot if it helps. Check the facts and private details, then share it where the intended readers can find it.