How to build in public as a solo founder and get useful feedback

You decide to build in public, take a screenshot of the dashboard you spent all weekend on, and write 'making progress.' A few founders like it. Nobody asks about the product. On Monday, you still have the same unanswered question about whether anyone needs what you are building.

The screenshot may look good. It just gives people very little to respond to. What problem were you trying to solve? What changed? Which decision is still open? Those details turn an announcement into a conversation someone can contribute to.

For a solo founder, sharing the work should help you do the work. This guide covers choosing a useful audience, writing specific updates, finding suitable testers, and deciding whether the effort is worthwhile. The product examples are fictional, written to show the choices involved rather than report results we achieved.

Editorial note: this article is part of an article exchange with Buildside. Its product description is based on its public website, not a hands-on review.

What does it mean to build in public?

Building in public means sharing selected parts of making your product while the work is happening. That might be a prototype, an experiment, a difficult decision, or a lesson from something that failed. People can see how the product is taking shape and respond before every choice becomes expensive to change.

You choose the boundaries. You can explain why you simplified onboarding without publishing revenue, customer messages, or your complete roadmap. A useful public record needs enough context to make sense. It does not need unrestricted access to your business.

There are several possible reasons to do it. You may want feedback from people who have built something similar, an introduction to a potential collaborator, or volunteers for a focused test. Pick the reason that matters now. Otherwise, every notification starts to look like progress, even when it changes nothing.

If the immediate problem is finding someone willing to buy, public updates can be part of the effort, but you still need contact with the intended customer. Our guide to finding customers on Reddit covers starting with an existing question from that person. Your build log gives them background once there is a reason to care.

Choose who you want to build in public for

Imagine you are building a tool that helps freelance designers get clear client approval. Other software founders can help you think about onboarding, technical shortcuts, and the work of launching alone. Designers can tell you how revisions and approvals happen in their businesses. Both conversations matter, but they answer different questions.

A founder might love a flexible permission system. A designer might tell you their client will not create an account. If you collect both reactions under 'positive feedback,' you miss the constraint that could determine whether the product gets used. Keep the person's role attached to the observation.

Before writing an update, finish this sentence: 'I want someone who has experienced this situation to help me understand this decision.' For the approval tool, that could be a designer who gets feedback from several people and needs to know who can sign off. The post becomes easier to write once the reader is specific.

You do not need every update to reach a buyer. Peer support has value when you work alone. Just be honest about the result you are seeking. A useful discussion about choosing a database can improve your engineering without providing any evidence of customer demand.

What should you share when you build in public?

Start with decisions you actually made this week. The material is usually already in your issue tracker, notebook, or unfinished draft. You removed a field, changed an assumption, discovered an awkward edge case, or decided to delay a feature. Explain the reason someone outside your project would understand.

A useful update gives the reader a situation, something observable, and a question or takeaway. The observable part can be small: two versions of a screen, a description of a test, or the step where a process breaks. You need enough evidence for someone to follow your thinking.

• A decision: what you chose, what you gave up, and why the tradeoff made sense.
• A prototype: the task it supports, what is clickable, and what is still a mockup.
• An experiment: what you tried, what happened, and what remains uncertain.
• A mistake: the assumption that failed and the change you made afterward.
• A question: one unresolved detail that someone with relevant experience could answer.

Match the question to what the reader can observe. A screenshot can help someone judge whether a label is understandable. It cannot show whether the workflow survives a week of real client revisions. Ask for the kind of feedback the material makes possible, then arrange a deeper test if you need one.

When nothing visible shipped, explain an investigation that changed your plan. Perhaps you discovered that an existing tool already handles the feature you wanted to build. That is a useful update if you can explain the consequence. There is no need to invent a milestone because your posting day arrived.

Build in public examples: turn a screenshot into a question

Consider two invented posts about the designer approval tool. The first reads: 'New dashboard is done. What do you think?' It asks the reader to inspect everything and decide what kind of feedback you want. A quick compliment is the easiest response.

A more specific version explains the decision and invites experience. It also labels the product stage so readers know what they are looking at.

I am prototyping a review page for freelance designers. I separated 'leave feedback' from 'approve this version' because a comment does not necessarily mean the work is signed off. The screenshot uses sample data, and the approval flow is not live yet. If you collect client approvals, how do you distinguish another revision request from a final yes?

Someone can answer that without signing up or understanding your entire product. They might describe an email convention, an approver field, or a contract that already solves it. Any of those answers can change the design. The post has opened a question about the work instead of asking strangers to rate a screen.

Your next update can close the loop: explain what you heard, which part applies to your audience, and what you changed. If you decided against a suggestion, explain the constraint. Readers should be able to see a connection between their contribution and your next decision, even when you do not implement their idea.

Choose a community by the conversation you need

Browse before committing to a platform. Read recent posts about products at your stage and inspect the replies. Are people asking specific questions? Do the responses contain experience you can learn from? Can you contribute something useful to the people already there?

A SaaS founder community is a sensible place to discuss early product decisions and the experience of building alone. A professional community closer to your buyer may be better for understanding a specialized workflow. Your own blog can hold a longer explanation you want to reference later. Give each place a purpose before adding it to your routine.

The format also needs to fit the stage. For example, the official Show HN guidelines ask for something people can try and exclude landing pages and sign-up pages. A concept update may be useful elsewhere while still being unsuitable for that format. Read the actual requirements before treating a platform as your next launch channel.

Start with one place you can participate in properly. Expanding to several feeds creates more replies to manage and more context to learn. Add another channel when you can name the missing audience or conversation it would provide, rather than copying the same announcement everywhere.

Where Buildside fits for SaaS founders

Buildside is a platform for SaaS founders to share progress, experiments, milestones, and lessons. Its public site includes founder profiles, product discovery, and beta opportunities. Visitors can browse public profiles, products, posts, and beta requests without an account; participation actions such as posting and following require joining.

That makes it relevant when you want a place to explain what you are building and meet other people doing similar work. The useful starting point is a concrete update with one open question, rather than a broad request to support your launch.

Before joining, browse Buildside's community and product overview. Look for projects close enough to yours that you can both learn and contribute. Its community guidelines emphasize sharing real work and learning from one another.

Treat it as a place to start relevant conversations. A profile or post does not guarantee beta testers, qualified buyers, or sales. Those outcomes still depend on who you reach and what you offer them.

How do you start building in public without an audience?

Begin by being useful in a small number of existing conversations. Answer a question you understand, describe a tradeoff you have encountered, or test something when a founder explicitly asks for that help. You can contribute before you have an impressive product story of your own.

Make your profile easy to understand. Say what you are building, who it is for, and whether it is a concept, a prototype, or available to use. Link to a page that explains the same thing. Someone who notices your contribution should not need to decode a slogan to understand your project.

Then publish an introduction with a narrow question. For the approval tool, explain the problem you are investigating and ask how people currently handle sign-off. Avoid asking a new community to visit a website, join a waitlist, review a roadmap, and share your launch in the same post. Choose one reasonable next action.

If the first post receives no replies, inspect the request before increasing the volume. Could someone answer it in a few sentences? Did you post where the relevant people participate? Did you provide enough context? Silence does not prove the idea is bad, but it also does not tell you to repeat the same post indefinitely.

Turn interest into a focused beta test

When you are ready to find beta testers, describe the person and the task. 'Looking for feedback' makes readers guess whether they qualify and how much time you need. 'Looking for freelance designers who collect approval from more than one client stakeholder' gives them a way to decide.

Explain what exists, what they would do, and the limits of the test. If you are showing a prototype, ask them to walk through a sample task. If they can use working software, explain the current restrictions and what help you can provide. Do not promise production reliability for an experiment.

I have a clickable prototype for reviewing one design revision. I am looking for a freelance designer to walk through the approval step using a sample project. It takes about ten minutes; no client files needed. I want to understand where the wording is confusing. Reply if that sounds relevant, and I can send the details.

This invitation is fictional, including the time estimate. For your own test, check the duration before publishing it. Once someone agrees, follow through on that exact request. Agreeing to review a prototype does not automatically mean they want a sales call or ongoing marketing messages.

Write down the task they completed and where they needed help. A compliment is pleasant, but a concrete obstacle gives you something to fix. Our guide to validating a startup idea on Reddit explains how to choose a test around the uncertainty you actually need to resolve.

Keep startup feedback connected to the person giving it

After a useful exchange, record the person's relevant situation, the observation, and your next action. A simple note might say: 'Designer works with one approver; understood the button; needs a record of the approved version.' Keep your interpretation separate: 'Investigate whether version history belongs in the first release.'

Conflicting feedback is worth inspecting. One person wants every reviewer to approve; another needs a single final decision-maker. Ask what differs in their work. You may have two customer situations that need different handling, rather than one interface problem you can solve by taking a vote.

Give suggestions a destination. Test now, revisit later, or decline with a reason. A growing list of requests can feel like evidence of momentum while leaving you unable to finish anything. The point of listening is to make a better decision, including the decision to keep the product small.

Share enough context while protecting private work

Use sample projects for screenshots and demos. Check browser tabs, notification banners, filenames, and background panels before publishing. A useful interface example rarely needs a real customer's identity or working documents. If a story depends on someone's contribution, ask before attributing it to them.

Describe sensitive lessons at the level that helps the reader. You can explain that a long import step confused a tester without publishing their recording. You can discuss a pricing assumption without exposing a private negotiation. Specificity comes from the decision and its context, not necessarily from identifying the person involved.

Keep planned features clearly separate from available ones. A mockup shared in an early update may circulate after the surrounding explanation disappears. Put the stage in the image or the accompanying description, and update your main product page when the plan changes. People should be able to check the current state in one place.

Use Reddit for relevant discussion, with the community's rules in view

A progress update that fits a founder community may be off-topic in a customer community. Before posting on Reddit, read the local rules about promotion, feedback requests, and recurring threads. Explain your connection to the product whenever you mention it.

Reddit's spam policy prohibits repeated or unsolicited mass engagement and points users to each community's additional rules. A build-in-public label does not change those boundaries. Contribute to the question being discussed, and ask moderators when the fit is unclear.

You can learn from a thread without posting your update beneath it. Save the problem for your research, investigate it, and share a suitable lesson where that kind of content belongs. If you later answer the original question, make the answer useful on its own and keep any product mention relevant and permitted.

Measure what the conversations changed

Suppose an update attracts twenty reactions and no substantive replies. Another receives two replies, one of which identifies a step that prevents a designer from using your prototype. For the purpose of improving that workflow, the second update gave you more to work with. Keep reach in your notes, but record the outcome beside it.

You can use a small record with the update link, intended audience, question, response, and resulting decision. Add the time spent writing and following up. After several updates, you can compare which subjects produced relevant exchanges and whether the effort fits the value you received.

If someone becomes a customer, ask how they found you and what helped them decide. They may have read several updates after receiving a recommendation elsewhere. Record that sequence as best you can instead of assigning the whole sale to the last post they clicked. A public history can help a buyer evaluate you without being the place they first discovered you.

Also record useful negative results. A tester who explains why their existing process is sufficient may save you from pursuing the wrong customer. That belongs in your product notes even though it would make an unimpressive growth screenshot. Decide what to change while the details are fresh.

A weekly routine that leaves time to build

Keep a short working note during the week. Add decisions and questions as they happen. At the end of a building session, choose one item that another person could learn from or help with. This reduces the chance of opening a blank composer and manufacturing a story just to stay visible.

As a starting experiment, reserve one short session to write an update and another to answer replies. Use a time budget that fits around your actual work. There is no universal posting frequency that makes a product succeed, and a difficult support week may reasonably take priority.

Review after a few weeks. Count useful conversations, completed tests, and decisions changed by evidence. Keep customer outcomes separate when they occur. If posting has mostly produced polite reactions, change the question or audience before adding more sessions. If it is consuming your building time without helping, reduce it.

Make the next update about one real decision

Choose something you are uncertain about today. Explain the situation, show what you can safely share, and ask a question a relevant person can answer. Browse a community such as Buildside to see whether that conversation fits, then contribute with enough context for someone to help.

We are taking the same approach to BeSeen, our coming-soon concept for solo founders finding relevant Reddit conversations. The product is not available yet, and pricing is TBD. If keeping track of those conversations is a problem in your own work, tell us where the process breaks down. That gives us a decision to investigate and something useful to share when we learn more.