Build in public has become one of those phrases that means everything and nothing. Some people use it to mean live-tweeting every todo list change. Others use it to mean polished case studies after a project is finished.

Neither is quite right. The version that actually builds an audience and helps your career sits in between.

What “Build in Public” Is Actually For

Before you do it, know why you are doing it. The reasons people build in public and whether they are good ones:

Good reasons:

  • Create accountability for finishing things
  • Attract early users and feedback
  • Build an audience of people interested in the same problems
  • Build a professional reputation in a specific domain
  • Document your learning for yourself (and others get value as a side effect)

Bad reasons:

  • Validation seeking (chasing likes is demotivating when the likes do not come)
  • FOMO from seeing others do it (if it does not fit your communication style, it will not work)
  • Generic “personal brand building” without a clear point of view

If you cannot answer “what do I want this to accomplish?” you will drift into either silence or noise.

The Oversharing Trap

The most common version of build in public that works against you: sharing every micro-update with no context or narrative.

“Just committed a fix for that annoying bug I mentioned yesterday!”

“Day 47 of building [project]! Still working on it.”

“Rough day coding, but made some progress.”

These updates have no value for the reader. They do not teach anything, they do not show thinking, they do not create a compelling story. After a few of these, people either unfollow or mentally mute you.

The problem is that these updates are easy to write. They feel like transparency. But they are noise that trains your audience to ignore you.

What Worth Sharing Actually Looks Like

Insights and learnings: Not “I fixed a bug today” but “I spent 3 hours debugging a race condition today. Here is how I found it and what I learned about [specific thing].”

Decisions and trade-offs: Not “working on the auth system” but “deciding between building auth myself vs using Auth0. Here are the trade-offs I am thinking about. Leaning toward [choice] because [reason]. What am I missing?”

Surprising discoveries: Things that were different from what you expected. These are inherently interesting because if you were surprised, others in similar situations would be too.

Milestones with context: Not “shipped v1.0!” but “shipped v1.0 after 4 months. Here is what I built, what changed from the original plan, the one decision I would make differently, and what is next.”

Failures with honest analysis: The failure posts that resonate are not self-pity. They are honest analysis of what went wrong and what you learned. Engineers respect intellectual honesty more than success theater.

The Frequency That Works

Most people either post too frequently (every small update) or too infrequently (waiting until something is “done enough” to share).

A sustainable rhythm for most people building in public:

  • Weekly: one substantive update on what you built, learned, or decided this week
  • Ad-hoc: when you have a specific insight or question that others would find valuable
  • Milestones: when you ship something, reach a metric, or make a significant pivot

Weekly substantive posts are achievable without feeling like you are drowning in your own feed. They give your audience a regular signal without flooding them.

What You Can Share Before Anything Is Ready

Build in public does not mean sharing finished work. It means sharing the journey. These are things worth sharing before anything ships:

  • Your thinking on a problem you are trying to solve
  • Architectural decisions you are wrestling with
  • Questions you are trying to answer before building
  • Early mockups or prototypes with an honest “this is rough” framing
  • Research you did before deciding on an approach

The key is that these things have inherent value - a reader can learn something, form an opinion, or see their own problems reflected in yours. The “half-finished work” that should not be shared is work that communicates nothing except “I am working on something.”

Platforms and Format

Twitter/X works for shorter updates and observations. LinkedIn works better for longer narrative posts and career-focused content. A blog works for deep dives and things you want to last beyond the social media ephemera.

For most developers, the hierarchy that makes sense:

  • Primary: Twitter/X for ongoing updates and community
  • Secondary: LinkedIn for reach into professional network
  • Archive: Blog for anything you want to be findable and referenceable later

The Audience Compounding Effect

Build in public only starts feeling worth it after a few months. In the first few weeks you are shouting into a void. The compounding comes from consistency - people start following because they anticipate the regular updates, and every post gets incrementally more visibility.

The engineers who give up after 3-4 weeks miss the part where it starts working.

Bottom Line

Building in public works when you share thinking, decisions, and learnings rather than activity. Aim for one substantive update per week, focus on what a reader would learn or find useful, and document your decisions and trade-offs honestly. Skip the “day 47, still working on it” noise. The audience you want to build will come from posts that teach something, not posts that just prove you are busy.