SOHEL DEV

Building a product used to be something founders did quietly. They worked behind closed doors, launched when everything looked polished, and only then started talking about the journey.

Build in public takes almost the opposite approach. Instead of hiding the process, you share parts of it while you are building: the idea, the experiments, the lessons, the progress, the failures, and sometimes even the numbers.

What Does Build in Public Mean?

Build in public means sharing useful parts of your product-building journey while the product is still being created.

You might share:

• What problem you are trying to solve
• Early product screenshots
• Features you are testing
• Technical lessons
• Customer feedback
• Launch preparation
• What failed and what you changed
• Milestones and progress updates

The interesting part is that people are not only watching the final product. They are watching the process.

Why Founders Build in Public

1. It Builds Trust Earlier

Trust usually takes time. When people repeatedly see you working on a real problem, explaining decisions, improving the product, and responding to feedback, they begin to understand how you think.

By the time you launch, some people may already feel familiar with the product.

2. It Helps You Build an Audience Before Launch

A common mistake is building a product first and thinking about distribution later.

Build in public lets product development and audience building happen together.

3. It Can Improve Product Validation

One of the biggest risks in product development is spending months building something nobody really needs.

Publicly discussing the problem and showing early solutions can create opportunities for feedback before too much time is invested.

4. It Creates Accountability

Sharing progress can create a healthy form of pressure. When you tell people what you are working on, it can become easier to stay consistent.

But I think this works best when the updates are realistic. Public accountability should support the work, not turn every day into a performance.

What Should You Share?

You do not need to publish revenue screenshots or private customer data. Build in public can be much simpler.

Content Type	Example
Progress	“Today I finished the onboarding flow.”
Lessons	A technical or business lesson from the week.
Decisions	Why you selected one feature over another.
Failures	Something that did not work and what changed.
Behind the scenes	Workflow, design process, automation, or product setup.

What You Should Not Share

Building in public does not mean sharing everything.

Some information should remain private, including:

• Customer personal information
• Passwords, API keys, or security details
• Private contracts
• Confidential client information
• Internal information that could create unnecessary risk

Build in Public Does Not Mean Posting Every Day

This is something I think is easy to misunderstand.

You do not have to turn your entire life into content. A weekly progress update can be enough.

The real value comes from consistency and usefulness, not from posting constantly.

A Simple Build-in-Public Content System

If I were building a small SaaS product, I would keep the system simple.

Build Product
      ↓
Write Down What Changed
      ↓
Choose One Useful Lesson
      ↓
Create Short Public Update
      ↓
Collect Feedback
      ↓
Use Feedback in Next Iteration

This way, content comes from the work itself. You are not constantly trying to invent something new to talk about.

A Practical Weekly Update Format

You could use a format like this:

This week I worked on:
- User onboarding
- API integration
- Dashboard improvements

What went well:
- Reduced one manual step

What did not work:
- First API approach was too complicated

What I changed:
- Simplified the workflow

Next:
- Test with real users

Simple updates like this can be easier to maintain than highly polished content.

Where Can You Build in Public?

The Risk of Building in Public

Build in public is not automatically good for every founder or every business.

Possible downsides include:

• Spending too much time creating content instead of building
• Sharing ideas before they are ready
• Feeling pressure to constantly show progress
• Making decisions for engagement instead of customers
• Oversharing sensitive business information

The system should serve the product. The product should not exist just to create content.

How Build in Public Can Help a SaaS Founder

For a SaaS founder, the approach can be especially useful because software products usually evolve through many small iterations.

That creates a natural stream of things to discuss:

• Feature decisions
• UI improvements
• Automation workflows
• Technical challenges
• User feedback
• Launch preparation

Even before the product has a large number of users, the journey itself can demonstrate your skills and thinking.

Build in Public and Personal Branding

One side effect of sharing your work consistently is that people begin to associate you with the problems you solve.

A developer who regularly shares useful lessons about SaaS development, APIs, and automation may gradually become known for those topics.

This can lead to more than product users. It may also create conversations with clients, collaborators, developers, agencies, or potential partners.

A Better Way to Think About It

I do not think the goal should be: “How do I get attention?”

A better question is: “What can I share from my work that might be genuinely useful to someone else?”

That mindset usually creates better content and a more sustainable process.

Final Thoughts

Build in public is not a magic growth strategy. It will not automatically create customers, and it cannot replace a useful product.

But it can make the product-building journey more visible. It can help you learn from feedback, build trust, document progress, and create an audience over time.

Start small. Share one useful lesson from what you are already building. Then keep going if the process helps you and the people following the journey.

Frequently Asked Questions

What does build in public mean?

Build in public means sharing selected parts of your product-building journey, such as progress, lessons, experiments, and feedback, while the product is still being developed.

Do I have to share revenue to build in public?

No. You can share product progress, lessons, technical decisions, customer insights, and experiments without publishing financial information.

Is build in public useful for SaaS founders?

It can be useful because it helps founders document progress, receive feedback, build trust, and create awareness before and after launch.

How often should I post build-in-public updates?

There is no fixed schedule. A consistent weekly update can be more sustainable than forcing yourself to publish every day.