Build in Public to Grow Your Startup

The short answer

To build in public and grow your startup, choose one current growth goal, share useful evidence from your work, reach relevant people, and invite one clear next step. Follow up with interested readers, use their feedback to improve the product, and measure conversations, product use, and business outcomes. A large following is not required, and public sharing does not guarantee growth.

Building in public can help your startup grow by making your work visible to potential customers, inviting useful feedback, and giving people reasons to trust you before they buy. The strongest approach connects what you share to a specific business goal: understanding a problem, recruiting early users, improving adoption, or earning referrals.

You do not need a large following to begin. You need something useful to show, a clear idea of who might care, and a next step that makes sense for them.

For an early-stage founder, the opportunity is straightforward: the work you already do can become the start of a conversation. Those conversations can help you build a better product and introduce it to people who need it.

What does building in public mean?

Building in public means sharing selected parts of your startup's development while the work is happening. That might include a product demonstration, a decision you are weighing, a lesson from customer research, or an experiment that changed your plans.

The useful part is context. A screenshot shows what you built. An explanation of the customer problem shows why it matters. A follow-up reveals whether your decision worked.

Some companies take transparency much further. Buffer, for example, publishes company finances, salary information, and other metrics through its public dashboard. That illustrates one approach to openness; it does not establish that publishing those details causes growth. Buffer's transparency dashboard.

Your approach can be narrower. Share what helps people understand your product and your judgment. Keep customer information, private conversations, credentials, and sensitive business details out of public updates.

A thoughtful explanation of one decision can be more useful than a running account of everything you did today.

Choose the growth problem you want to solve

Before deciding what to post, decide what your startup needs.

If you are still exploring an idea, your immediate goal might be finding people who experience the problem. If you have a working product, you might need users willing to try a specific workflow. If people sign up but disappear, your priority could be understanding where they get stuck.

Each situation calls for different public updates.

A founder researching appointment scheduling could describe a frustrating booking process and invite practitioners to explain their current workaround. A founder with a working scheduler could demonstrate how it handles cancellations and invite someone to test it.

Once customers are using the product, updates might explain overlooked features, show an improved setup process, or share a customer story with permission.

This keeps public sharing connected to the company's actual needs. Y Combinator's startup guidance emphasizes launching, talking to users, and improving the product through iteration. Treat your public activity as a way to support that work. YC's Essential Startup Advice.

Choose one goal for the next month. Make it concrete enough to review: have five conversations with potential customers, recruit three beta testers, or learn why new users abandon setup.

Those are planning targets, not promised results. Their value is that they give your effort a direction.

Give every update a reader, evidence, and a next step

A practical way to prepare a post is to answer three questions:

1. Who is this useful for?

2. What can I show that makes it credible?

3. What would I like that person to do next?

Start with a recognizable problem. Then show something from your work: a short demonstration, an anonymized observation, a before-and-after workflow, or a decision with its reasoning.

Finally, offer one relevant next step.

Suppose you are building software for freelance designers. An update announcing "new dashboard shipped" leaves readers to work out the benefit. A more specific update could explain how the dashboard brings overdue invoices into one view, then show that workflow using sample data.

Your invitation could be equally specific: "If you manage client invoices in a spreadsheet, I'm looking for someone to test this workflow."

That gives the right person a reason to respond.

Avoid attaching several competing requests to one update. Asking people to follow, subscribe, comment, share, and start a trial makes the intended action unclear.

A research post can ask a question. A demonstration can invite a test. A useful lesson can stand on its own. Choose the next step according to what you shared and what you need to learn.

Turn replies into customer conversations

A public reply is an opening. Follow through while the context is fresh.

If someone describes the problem you are investigating, ask about a recent example. What happened? How did they handle it? What made the workaround difficult? Have they already tried to solve it?

These questions help you understand actual behavior. A general statement such as "I would use this" gives you less to work with than an explanation of what someone did last week.

When the product is ready, offer a relevant demonstration or invite them to try the workflow they described. Help them get started, then ask what happened.

Paul Graham's essay on early startup work argues that founders often need to recruit users manually and give them direct attention. Public updates can create opportunities for that personal follow-through. Do Things that Don't Scale.

You can also close the conversation publicly. Explain what you learned and what you changed, while protecting the contributor's privacy.

For example: "The first version assumed invoices had fixed due dates. Feedback showed that some designers bill around project milestones, so I'm testing a different setup."

That update gives previous contributors a reason to return and helps new readers understand how the product is developing.

Share where potential customers can recognize themselves

Start with a place where you can reach relevant people and participate consistently.

Founder communities can help you find peers, collaborators, and practical feedback. Communities centered on your customers' work can help you understand their language, habits, and buying decisions.

If you sell to accountants, seek conversations about accounting workflows. If your product serves developers, demonstrate the technical problem it solves. If you serve local businesses, speak in terms of the tasks those owners manage.

You can participate in both founder and customer communities, but give each audience something relevant.

Learn how people communicate before posting. Answer questions when you have useful knowledge. Share examples that fit the discussion, and follow the community's rules about promotion.

Starting without an audience means doing this work deliberately. Find existing conversations, contribute something helpful, and let interested people discover your product through that contribution.

Keep your profile clear, too. Someone who finds your update should be able to understand who the product serves and where to learn more.

A four-week example: building an invoice reminder tool

Consider a hypothetical founder creating an invoice reminder tool for freelance designers. The immediate goal is to recruit a few suitable testers and understand their existing workflow.

Here is how four weeks of public updates could support that goal. This is a suggested experiment, not a report of actual results.

Week one: explore the problem. Share an observation about the awkwardness of chasing late payments. Ask designers how they decide when to follow up and what they currently use. Avoid presenting your proposed solution as settled. Use the replies to identify people with relevant experience.

Week two: show a small solution. Publish a short demonstration using fictional invoices. Show one task: reviewing an overdue payment and preparing a reminder. Explain which part is ready and which part still needs work. Invite suitable respondents from the first week to test it.

Week three: share what testing revealed. Describe a specific issue you observed, such as testers struggling to choose an appropriate reminder tone. Explain the change you are considering and why. Ask testers to try the revised workflow rather than relying only on opinions about a screenshot.

Week four: review use and decide what comes next. Follow up with testers to learn whether they used the tool for a real task. Share what you can support with evidence, acknowledge the limits of the small sample, and explain your next decision. If you are ready to charge, make the offer and its conditions clear.

The sequence creates continuity. People can see the problem, the proposed solution, the feedback, and the response.

It also produces several possible outcomes. You might find willing testers, discover that your initial audience is wrong, or learn that the problem is too occasional to support the product you imagined.

Each outcome can inform a useful decision. The experiment succeeds when it helps you act on better evidence.

Build a routine you can maintain

Public sharing becomes difficult when every update requires a new idea, a polished graphic, and an hour of editing.

Capture material during normal work. Keep brief notes on customer questions, product decisions, demonstrations, and surprising results. At the end of the week, choose the item most relevant to your current goal.

A starting routine could be one useful update after a meaningful change, a short session to answer replies, and a weekly review of what you learned.

Set a time limit that fits your workload. If preparing posts repeatedly delays customer calls or shipping, simplify the format or reduce the frequency.

Be deliberate about what you share. Use sample data in demonstrations. Get permission before identifying a customer or quoting a private conversation. Share lessons from a disagreement without turning another person into content.

You can be candid about uncertainty while respecting those boundaries.

Public commitments deserve care as well. Describe an experiment as an experiment. Explain what is available now, and distinguish it from an idea you may explore later.

Measure what happens after the post

Views and likes tell you that an update received attention. To judge its value for your startup, look at what followed.

Keep a simple record of the update, its intended audience, and the action it invited. Then note relevant conversations, product visits, trial starts, completed setup, or continued use.

Choose measures that match your stage. During research, detailed accounts from potential customers may be the most useful outcome. During a beta, you may care about whether testers complete the intended task. With a paid product, you may track purchases and whether those customers stay.

Ask new users how they found you. Where practical, use distinct links for different channels. Attribution will still be incomplete: someone might read several updates before visiting directly.

Treat the record as evidence for decisions rather than a perfect explanation of growth.

If updates attract attention but few relevant conversations, reconsider the topic or audience. If people visit but rarely try the product, review the offer and landing page. If they try it and stop, investigate their experience.

The response you need may be a product improvement, a clearer invitation, or a different audience. For a deeper review, see Buildside's guide to measuring building-in-public impact.

Give your public work a lasting home

Individual updates are easier to understand when readers can connect them to a product and its history.

Maintain a clear product page and a small collection of useful demonstrations or development notes. Link related updates so someone arriving later can see what changed and why.

This also makes follow-through easier. When a potential customer asks how a feature works, you can share the relevant explanation. When a collaborator wants context, you have something concrete to show.

Buildside provides a place for SaaS founders to share progress, launches, experiments, questions, and lessons, alongside founder and product discovery. It can serve as a home for those ongoing updates. Explore Buildside.

Keep participating where your customers discuss their work, too. A founder community and a customer conversation serve different purposes, and both can contribute to your startup's development.

Start with one useful update

Choose a real problem you worked on this week. Explain who experiences it, show what you learned or changed, and invite one relevant response.

Then follow through.

The next useful step might be a conversation, a test session, or a change to the product. Share the outcome when you have something concrete to say.

Over time, this gives people a clearer view of your startup: what it solves, how you make decisions, and how you respond when the evidence changes. That is a practical foundation for earning attention, building trust, and growing a product people want to use.

Sources

• Buffer: Open company dashboard

• Y Combinator: Essential Startup Advice

• Paul Graham: Do Things that Don't Scale

• Buildside: Building in public for SaaS founders

• Buildside: Measure whether building in public helps your startup

Frequently asked questions

A note from Uriel Bitton

Public updates are most useful when they lead to better decisions, relevant conversations, and product use. Choose one growth goal, share evidence from the work, and follow through on the responses.

Keep building with us

Get practical founder lessons and product updates in your inbox.

Subscribe or Join Buildside.

Keep reading