# How to Build in Public as a Bootstrapped Founder > Build in public without turning it into a full-time job: choose one home base, share decisions and evidence, protect customer data and measure useful replies. - Canonical: https://zeroraised.com/blog/how-to-build-in-public-as-a-bootstrapped-founder - Published: 2026-10-25 - Author: ZeroRaised Team (https://zeroraised.com/blog/authors/zeroraised) - Publisher: ZeroRaised (https://zeroraised.com/) - Section: Building - Tags: building-in-public, bootstrapping, launch-strategy, distribution Building in public means sharing the work while it is still unfinished: the decision you made, the experiment you ran, the problem you hit and what you learned. It is not a performance of productivity, and it is not a substitute for talking to customers. The useful version is small, consistent and specific. It gives potential users a reason to trust the maker, gives the maker a record of decisions and creates material that can be reused in launch pages, emails and articles. **TL;DR** - Pick one home base you control, such as a blog or newsletter, and one distribution channel. - Share decisions, experiments, trade-offs and failures with enough context to be useful. - Protect customer data and private conversations. - Publish on a cadence you can sustain for months. - Measure replies, conversations, signups and retention, not follower counts. **Disclosure:** ZeroRaised publishes this guide and is a launch and discovery site for bootstrapped products. It appears near the end as one place to present a product, not as a guaranteed audience. ## What building in public is, and what it is not Building in public is the practice of sharing useful parts of the product and business process while they are still in progress. The word "public" can be misleading. You do not have to publish everything. You choose what is useful, safe and consistent with your obligations. It is: - a decision log with context; - a way to explain what the product is becoming; - a feedback channel; - a record of experiments and results; - a source of material for later marketing. It is not: - a daily diary with no reader in mind; - a growth hack that guarantees an audience; - a reason to publish customer data; - a substitute for direct outreach or sales; - a performance of hustle. The best build-in-public writing teaches something. It shows the reader a problem, the options considered, the decision and the consequence. That is useful even to someone who never buys the product. ## Why build in public? There are four legitimate reasons. **Accountability.** A public commitment to a weekly note can help a solo maker keep moving. The audience does not have to be large for the commitment to work. **Feedback.** A specific post about a trade-off can produce a useful reply from someone who has faced the same decision. That is often more valuable than a generic request for feedback. **Distribution.** A build log creates a body of work that people can find through search, communities or referrals. It can also give a launch page something to link to. **Trust.** A buyer who can see how the product was made, how the maker handles problems and what the maker values has more context for the decision. None of these is guaranteed. A build log with no useful content will not produce accountability, feedback, distribution or trust. The work is still the writing. ## Choose one home base and one channel The biggest mistake is spreading the same update across five platforms and doing none of them well. Choose one place you own and one place you distribute. **Home base:** a blog on your own domain, a newsletter or a page on your product site. You control the URL, the archive and the relationship. This is where the canonical version lives. **Distribution:** one channel where your buyers already spend time. It could be a community, a social platform, a newsletter or a forum. The goal is to bring the right people back to the home base, not to chase reach everywhere. If you already have a newsletter, use it. If you do not, a simple blog with an RSS feed is enough. Add email later when people ask to hear more. The [free marketing channels guide](https://zeroraised.com/blog/free-marketing-channels-for-bootstrapped-makers) can help you choose the distribution channel. The [waitlist guide](https://zeroraised.com/blog/how-to-build-a-waitlist-before-launch) covers collecting permission to stay in touch. ## What to share A useful build log answers a question the reader might have. It does not need to reveal everything. ### Decisions and trade-offs Explain a choice and the alternatives you rejected. For example: why you chose a simpler pricing model, why you dropped a feature, why you changed the onboarding or why you picked one platform over another. The detail is what makes it useful. "We simplified pricing" is an announcement. "We moved from three plans to two because the middle plan created a decision the buyer could not make without a call" is a lesson. ### Experiments and results Describe an experiment, how you measured it and what happened. Be honest about inconclusive results. A failed experiment with a clear method is more useful than a success story with no context. Do not invent numbers. If the sample is small, say so. If the result could have another cause, say that too. ### Problems and failures A post about a bug, a launch that did not work or a customer conversation that changed your mind can be valuable. It shows how the maker thinks and gives readers permission to share their own problems. Be careful with customer stories. Ask permission, remove identifying details and do not turn a private conversation into content without consent. ### Behind-the-scenes work Show the process: the design iteration, the test that caught a problem, the checklist, the support workflow. These posts are often more useful than high-level reflections because they are concrete. ### Product changes When you ship something, explain what changed and why. A release note is for existing users; a build-log post can explain the decision behind the change. The [release notes guide](https://zeroraised.com/blog/how-to-write-release-notes) covers the former. ## What not to share Some information should stay private: - customer data, emails, account details and private messages; - credentials, API keys and internal endpoints; - security vulnerabilities that are not fixed; - information covered by a contract or a partner agreement; - personal details about customers or employees without consent; - unverified claims about revenue or growth that could mislead. If you are unsure, leave it out. A build log does not need to be a transparency contest. ## Choose a cadence you can sustain A cadence is a promise to yourself and, eventually, to readers. Pick one you can keep for months. Options: - **Weekly note:** one short post about a decision, experiment or lesson. - **Monthly recap:** a longer summary of what changed, what worked and what did not. - **Milestone post:** a post when something meaningful ships or changes. - **Thread or newsletter:** a short sequence of related notes. Weekly works for many makers because it creates a rhythm without requiring a huge essay. Monthly works when the work is slower or the audience prefers depth. Batch the work. Write notes during the week, then edit and publish on one day. Keep a running list of topics so you are not starting from a blank page. Do not commit to a daily cadence unless you can genuinely sustain it. A short burst followed by silence is worse than a modest rhythm that continues. ## Measure the right things Build-in-public metrics are easy to misread. A large follower count does not prove that anyone uses the product. Measure: - **Replies and conversations.** Did someone respond with a question, an experience or an introduction? - **Qualified visits.** Did the right kind of person click through to the product? - **Signups and activations.** Did the content lead to a useful action? - **Retention.** Did the people who arrived stay? - **Inbound opportunities.** Did a customer, partner or writer mention the post? Ignore, or at least do not optimise for: - follower counts; - likes and impressions without a next step; - the number of posts published; - comparisons with other makers who have different products and audiences. A single reply from the right person can be more valuable than a thousand impressions. The [first 100 users guide](https://zeroraised.com/blog/how-to-get-your-first-100-users) explains how to turn conversations into users. ## Risks and how to handle them **Competitors.** A competitor can read your build log. That is usually acceptable. Do not publish a roadmap that would let a competitor front-run a launch or a partnership. **Privacy.** Customer stories are not yours to tell without permission. Anonymise data and ask before quoting. **Vanity.** It is easy to optimise for applause. Ask whether a post would be useful to a buyer or another maker even if nobody liked it. **Time.** Writing takes time away from the product. A weekly note is usually sustainable; a daily content operation is not, unless content is the product. **Misleading comparisons.** Revenue, growth and traffic numbers can be misleading without context. If you share a number, explain what it measures and what it does not. ## Building in public without an audience Start with the people you already know. Send a short note to five or ten people who have the problem, telling them what you are working on and what you learned this week. Ask one specific question. Publish the note on your own site so it has a stable URL. If the note is useful, the audience grows from the work. If nobody reads it, you still have a record and a clearer explanation of the product. Do not wait for an audience to start. The first posts are practice. The audience, if it comes, arrives because the posts are useful. ## A 30-day build-in-public plan This is a sequence, not a guarantee. **Week 1: choose the home base and the cadence.** Set up a simple blog page or newsletter. Write down the format and the publishing day. **Week 2: publish the first note.** Share one decision and the alternatives you rejected. Include a concrete detail and a question for the reader. **Week 3: publish a second note and distribute it.** Share it in one community where the topic fits. Reply to every response. **Week 4: review and adjust.** Look at replies, visits and signups. Decide whether the cadence is sustainable and what to write next. ## Where ZeroRaised fits ZeroRaised is a launch and discovery site for products built without institutional venture capital or accelerator equity. If you have a product people can try, you can [submit it here](https://zeroraised.com/submit). The [pricing page](https://zeroraised.com/pricing) explains the current options, and the [archive](https://zeroraised.com/archive) shows how products are presented. A build log can feed a launch page: the decisions, screenshots and lessons become the context a visitor needs. The [launch announcement guide](https://zeroraised.com/blog/how-to-write-a-product-launch-announcement) and the [Indie Hackers launch guide](https://zeroraised.com/blog/how-to-launch-on-indie-hackers) cover the next step. ## Sources and further reading - [ZeroRaised: why we built ZeroRaised](https://zeroraised.com/blog/why-we-built-zeroraised) - [ZeroRaised: how to launch on Indie Hackers](https://zeroraised.com/blog/how-to-launch-on-indie-hackers) - [ZeroRaised: free marketing channels](https://zeroraised.com/blog/free-marketing-channels-for-bootstrapped-makers) - [Paul Graham, Do Things that Don't Scale](https://www.paulgraham.com/ds.html) ## Frequently asked questions ### What does building in public mean? Building in public means sharing the process of building a product, including decisions, experiments, setbacks and lessons, while the work is still in progress. It is not the same as publishing every internal detail or every customer conversation. ### Do I need an audience to build in public? No. Start with a small group of people who have the problem, share useful notes with them and let the audience grow from the work. A public build log can also help you think more clearly and create a record of decisions. ### What should I not share? Do not share customer data, private conversations, credentials, unreleased security details or information that could harm a customer or partner. Ask permission before quoting anyone, and check your contracts and platform rules. ### How often should I post? Choose a cadence you can sustain for months, such as one short note a week or one longer recap a month. Consistency matters more than frequency. It is better to publish a useful note every week than a burst of posts followed by silence. ### Does building in public help sales? It can help by creating trust, showing how the product works and giving people a reason to start a conversation. It is not a guaranteed acquisition channel, and it works best when the content is genuinely useful to the buyer.