Quick answer: Build in public is the practice of sharing the product's development, the numbers, and the decisions as the work happens. The audience follows the build, and the launch starts with the audience already in place.

What to share

  • The shipped work. The feature, the fix, and the deployment.
  • The numbers. The users, the revenue, the traffic, and the churn.
  • The decisions. The architecture, the pricing, the trade-off.
  • The mistakes. The failure, the cause, and the fix.
  • The learning. The thing that changed the founder's mind.
  • The roadmap. The next steps and the questions.

The rules

  • Be honest. The positive-only update is an advertisement, not the build.
  • Be specific. The real number, the real date, the real customer.
  • Be regular. The cadence matters more than the volume.
  • Be useful. The reader should learn something, not just cheer.
  • Protect the secrets. The customer data, the proprietary strategy, and the legal details stay private.

The cadence

  • The short update: a few times a week, the shipped thing.
  • The weekly or monthly recap: the numbers and the learning.
  • The milestone post: the launch and the major releases.

The content calendar schedules the cadence.

The platforms

  • X. The frequent build updates and the threads.
  • LinkedIn. The longer lessons.
  • The blog. The deep GEO-friendly post.
  • dev.to / Hashnode. The technical build story.
  • The niche community. The product and developer communities.

The honest numbers

The numbers are the strongest part of the build:

  • The revenue is the recurring revenue, defined.
  • The users are the active users, not the signups.
  • The failure is stated with the reason.
  • The traction slide uses the same honesty.

The boundaries

  • Don't share the customer's private data.
  • Don't announce the product that isn't real.
  • Don't frame the negative as the marketing stunt.
  • Don't post the employer's confidential information.
  • Don't let the posting replace the building.

The risks

  • The copying: a competitor can watch. The execution is the moat.
  • The pressure: the public metric can distort the decisions.
  • The time: the posting can take over the build.
  • The early stage: the first months may have no interesting number; the decision and the learning are the substitute.

The build-to-launch

The build-in-public audience becomes the launch audience:

The side project and the developer product

The developer product is the natural fit; the developer marketing guide explains why the engineering work is the marketing.

Frequently asked questions

Do I need the revenue to build in public? No; the decisions, the users, and the mistakes are the early content. Is the public repository required? The open-source launch is one form; the closed product can still build in public. Can I share the negative numbers? The honest negative is the trust-building part; the ratio and the response matter. What if the competitor watches? The execution and the speed are the moat; the audience is the benefit.

Share the real work on a regular cadence, keep the customer's secrets, and let the honesty build the audience before the launch.

Related guide: the Product Hunt launch hub.

Related guide: the first 100 users guide.