Private Founder Feedback: Check Your Demo Links

The short answer

Before choosing a platform for private founder feedback, check the audience of the conversation and every linked demo. Confirm where comments will appear and who can read them, then test the intended reviewer’s route. Publish your own resulting product decision with an appropriate public example.

Before choosing a platform for private founder feedback, check both the conversation’s audience and the audience of every demo link you share. A direct message can contain a file that anyone with its link can open. Choose the discussion space, file permissions, and place for replies together, then verify that your intended reviewers can use them.

For SaaS founders building in public, this helps preserve two useful activities. You can discuss a rough product decision with selected peers and still publish a clear account of what you learned. The material in each exchange should match the people you intend to reach.

This guide examines documented workflows checked on November 6, 2026. Buildside publishes this Journal and is one of the platforms discussed. The worked example is fictional. No private conversations were read, messages sent, or live account permissions tested for this article.

Choose the feedback exchange you want to have

Start with one product question and the people equipped to discuss it. A peer might help you reason through an approval screen, while the intended buyer might be needed to explain purchasing authority. That choice tells you whom to invite and what evidence they need to see.

Buildside’s guide to finding useful founder feedback routes questions by the evidence required. Once you have identified a suitable audience, check how that audience will receive the request. A public post, a direct conversation, and a project discussion can each support feedback with different readers.

For the broader choice of a public home, reach channel, or peer space, use Buildside’s platform comparison. Here, the decision is narrower. Can the particular people you invite open the material and respond in the audience you intend?

Write down the desired arrangement before looking at controls. For example, you might want two named peers to view a prototype, leave comments visible to each other, and discuss the result in a shared conversation. Alternatively, each reviewer might need a separate exchange. Those choices create different expectations about who will read the feedback.

Check the conversation and the linked material separately

A conversation’s access controls describe that conversation. A linked file has its own controls. Check both before deciding that the whole exchange is limited to the people you invited.

Google Drive’s sharing documentation provides a concrete example. It distinguishes Restricted access, where only people given access can open a file, from Anyone with the link, where a person holding the link can open it without signing into a Google Account. Drive also provides viewing, commenting, and editing roles, with work or school accounts subject to their organization’s sharing limits. Google Drive’s file-sharing guidance

If you paste an Anyone with the link URL into a private message, the file keeps that wider access setting. The private message determines where you placed the URL. The file setting determines who could open it if they received that URL.

Follow the material far enough to understand the review. A slide deck might link to a recording or a second prototype. Open those destinations and inspect their audiences too. Choose the smallest set of material needed to answer the product question so there are fewer links and permissions to reconcile.

What the documented conversation surfaces let you check

Buildside describes direct messaging as a private conversation workflow separate from publishing a community post. Its guide also says that available contact options depend on a member’s privacy settings and account permissions. It is a documented option for following up on a relevant product discussion when the contact controls are available. The linked demo still needs its own sharing check. Buildside’s messaging guide

GitHub Discussions offers a project-centered alternative. GitHub says discussions must be enabled and that people with access to the repository or organization can participate. Its repository documentation distinguishes public access from private access, which includes the owner, people explicitly given access, and certain organization members. For a repository discussion, inspect the actual repository audience before treating it as a conversation with only your invited reviewers. GitHub Discussions documentation, GitHub’s repository visibility guidance

These documented differences help you choose a workflow. An existing direct exchange may suit a bounded peer question. A repository discussion may suit a project whose authorized participants need to return to the decision. In either case, confirm the readers of the specific place you use and inspect every linked artifact.

These are source-based workflow observations. They provide no measurement of response quality or proof that a particular peer will help. Keep the choice tied to the question and the audience you have already identified.

Make a four-part audience record

A short private note can hold the information you need before sending the request.

• Conversation. List the intended readers, where the discussion will happen, and any additional members who can access that space.

• Demo. Record the exact file or prototype link, who can open it, and whether permissions also come from a folder, group, or project.

• Replies. Record whether feedback will appear in the conversation, on the file, or in separate replies. Identify who can read those comments.

• Public follow-up. Decide what you can publish about your own product decision and what would need a reviewer’s permission to share.

Folder access deserves a check when you use Drive. Its documentation explains that files inherit sharing permissions from their parent folders. Inspect that inherited access along with any direct invitations. A list containing two named reviewers can coexist with another route that grants access to more people. Google Drive’s explanation of folder inheritance

Keep the note proportionate to the task. You do not need to publish the record or expose a reviewer’s identity. Its purpose is to make the route from your request to the evidence and replies understandable before anyone spends time on it.

A fictional prototype review with two peers

Imagine a founder building a procurement-request SaaS. Their current question concerns a handoff screen. When an approver returns a request for more information, should the person who submitted it see the requested change beside the status or inside a separate activity view?

The founder wants input from two peers, Isha and Leo, who have worked on similar business workflows. They plan to discuss the reasoning privately, then share the resulting product decision in their public build log. This is a fictional scenario with invented people, product details, and review steps.

The founder prepares a short deck using invented suppliers, amounts, and request names. It shows the same task in two layouts. The deck’s sharing setting allows anyone with its link to open it. The founder then drafts private messages inviting the two peers to review it.

At this point, the intended conversation audience is two people. The deck’s potential audience includes anyone who receives its link. The founder wants the rough alternatives to remain within the selected review, so they need to reconcile that difference before sending.

They inspect the deck’s sharing settings and parent folder, choose access for the intended reviewers, and confirm the role needed for the task. If comments will be collected on the deck, they tell both reviewers who can read those comments. If the peers should respond independently, the founder chooses separate reply routes and makes that arrangement clear.

The founder also creates a separate public illustration of the handoff problem. It contains only the example and question they are ready to publish. This lets people following the product understand the work while the selected review uses its own material and audience.

Give reviewers a request they can complete

The proposed request in this fictional example could read as follows.

I’m comparing two ways to show a request returned for more information. The deck uses invented procurement data. Could you review the handoff on slides two and three and tell me where you would expect to find the requested change? Isha and Leo have access, and both can read comments left on the deck. I’ll share my resulting design decision publicly and ask before quoting or identifying either of you.

That request names the task, material, readers, reply location, and intended follow-up. A reviewer can assess the commitment and the audience before opening the deck.

The exact wording should follow the arrangement you actually make. If only one peer can read a message, describe that exchange accurately. If the review is in a repository discussion, identify the project audience that can see the thread. Preserve those conditions when you copy a request into another tool.

Verify the recipient’s path before asking for feedback

Test the full route with a harmless sample using the same sharing arrangement you plan to use. Inspect access through an intended reviewer account where you are authorized to do so, or ask a willing reviewer to confirm what opens. Keep the check limited to your own sample material.

Also check the view from an account outside the intended audience, or while signed out when that tests the relevant setting. A file opening for its owner tells you little about the reviewer’s path. A signed-out block is one observation about that route, while named accounts, groups, and inherited permissions still need inspection.

Confirm that the intended person can reach the right version and perform the requested action. Viewing a prototype and commenting on it may require different roles. If the person encounters an access problem, correct the relevant permission or choose a different review arrangement. Recheck the audience after the change.

Describe the result narrowly in your private note. You might record that the intended account could view and comment on the sample, while the checked outside account could not open it. That is useful evidence about the checks you performed. Keep any broader confidentiality or security claim within what you can actually establish.

Bring the learning back to your public product history

After the fictional review, suppose the founder decides to put the requested change beside the returned status and test whether intended users can find it. Their public update can show the new synthetic example, explain the reasoning behind the choice, and name the next test.

The update can stand on its own without reconstructing the private conversation. If the founder wants to quote Isha, identify Leo, or reproduce an annotated screen, they ask for permission covering that specific material and the place it will appear. Confirm permission for the public wording separately from the review invitation.

Check the links in the public update afresh. Use the public illustration you prepared and inspect its access and contents. A copied private-review URL would send readers to a different audience arrangement. Likewise, check that the public illustration points only to material you intend those readers to reach.

When the review ends, revisit access to the draft material according to the arrangement you made. Keep the decision and next step in your own product notes so your public building habit can continue without depending on a private thread.

Questions founders ask next

Can I use the same file for public updates and a private review?

You can, if its contents and audience suit both activities. Check who can read the file and its comments before using it in both places. A separate public example is often easier to manage when the private review contains rough alternatives or material intended for selected readers.

Does a blocked signed-out link prove that only my reviewers have access?

No. Inspect named users, groups, inherited permissions, and the conversation’s membership as well. The signed-out check covers one route and should be recorded with that limit.

Do private replies count as product validation?

They can inform a decision, but describe what the reviewers actually did and whom they represent. Peer reasoning about a prototype and an intended user completing a task provide different evidence. Use the review to decide what to investigate next.

Sources

• Buildside’s direct messaging workflow

• GitHub’s explanation of project discussions

• GitHub’s repository visibility and access guidance

• Google Drive’s file-sharing roles, link access, and folder inheritance

• Buildside’s guide to finding useful founder feedback

• Buildside’s broader build-in-public platform comparison

Frequently asked questions

A note from Uriel Bitton

I share practical lessons from building Buildside and learning alongside SaaS founders.

Keep building with us

Get practical founder lessons and product updates in your inbox.

Subscribe or Join Buildside.

Keep reading