A public SaaS demo should start in a known state, give visitors one task to try, and let them return to the same starting point. That makes the feedback easier to interpret. If every visitor inherits a different workspace, you won't know whether they struggled with your change or somebody else's leftovers.
When you build in public, the demo is part of the conversation. A screenshot can explain what changed. A repeatable demo lets another person examine the behavior behind that explanation. It doesn't prove demand, but it can make a technical discussion much more concrete.
Define one task before preparing the workspace
Use a task with a visible finish. For a fictional invoice-review tool, the task might be: import the supplied sample file, find the row that needs attention, correct it, and review the final total. This is a worked example, not a description of Buildside's features.
Don't ask visitors to “explore everything” and then compare their reactions as though they attempted the same work. Exploration is useful when that is the research question. It is less useful when you need to understand why a particular step fails.
Write the task in customer language. “Review this sample invoice before export” gives someone an outcome. “Click the orange button, open the second tab, and edit row four” mainly checks whether they can follow your directions.
Make the initial state inspectable
For the fictional demo, prepare one small sample file with invented businesses and amounts. State how many rows it contains, which condition needs attention, and what the completed result should mean. Keep the fixture small enough that you can check it manually.
Record the demo version and the sample's version together. A person reporting a problem should be able to tell you which release they tried. If you change the sample halfway through collecting feedback, note that change rather than combining every response into one pile.
The demo's first screen should explain what is real and what is simulated. A visitor shouldn't have to wonder whether an action sends an invoice to a customer. Keep external side effects out of the public sample path unless they are necessary, clearly explained, and deliberately authorized.
Keep each visitor's work separate
A shared editable workspace can make a demo hard to interpret. One visitor clears a row, another sees the cleared state, and a third tries to reproduce a problem against different data. Their reports describe different starting conditions.
Choose a separation model that fits the product. A private session, a disposable workspace, or a local sample state may work. Each has different implementation costs and limits. You don't need to expose those details in the invitation, but you do need to know which behavior your demo provides.
Check the boundary with two sessions before sharing the link. Change something in one, then examine the other. If changes appear in both, decide whether the demo should be read-only or whether you need to fix isolation first. Don't label a workspace private unless you have verified that claim.
Treat reset as a user task
A reset control should say what it resets. In our example, it restores the sample import and removes the edits made during that demo session. It should not affect a real account, another visitor's work, or a production dataset.
Test reset after a successful run, after an error, and after leaving the task halfway through. Then repeat the task. The second attempt should start with the documented sample and should not inherit a stale success message, an unfinished upload, or a hidden selection from the first attempt.
Also check a page reload. Decide which state should persist and describe it accurately. A reset button that changes the screen while leaving old data underneath can produce misleading feedback even when it appears to work.
Separate a conversation from an observed test
A visitor saying “this seems easy” is giving you an opinion. Watching them finish the task without help gives you a different kind of evidence. Neither should be silently substituted for the other.
Nielsen Norman Group distinguishes interviews, which collect reported experiences, from usability tests, which observe interaction with a design. Apply that distinction to public demo feedback. A comment thread can help you find a question to investigate; it isn't automatically an observed usability session.
If you arrange a test, explain the task and observe where the person hesitates. Ask what they expected after the attempt. Don't coach them through every uncertain step and then record the result as independent completion.
Give bug reports a small useful structure
Ask for the starting state, task attempted, steps taken, expected result, and actual result. Include the demo version and relevant browser information when those details could affect behavior. Make screenshots optional and tell people to omit private data.
GitHub's issue-template documentation explains how templates and forms can encourage structured reports. You can apply the same idea to a simple feedback form. Don't require a public repository account from a nontechnical visitor unless that is appropriate for the audience.
A useful fictional report would say: “On demo version B, I imported sample A, edited the flagged row, and the total still showed the old value after I saved.” That gives you a sequence to replay. “The importer is broken” leaves the starting conditions unclear.
Publish a short demo contract
Before sharing the link, write a few plain sentences covering the starting sample, the task, the finish, the reset behavior, and known limits. Think of this as a promise about the demonstration, not about your entire product.
For example: “This demo uses fictional invoice data. Try correcting the flagged row and checking the review total. Reset restores the original sample for your session. Export is simulated and no messages are sent. This version doesn't support your own files.”
That contract is a proposed format for clearer feedback. It isn't a claim that this exact design has been tested. Adapt it to the behavior you have verified. If a limitation changes what someone can learn, put it beside the invitation rather than hiding it at the end of a long release note.
Link public progress to a testable change
A build-in-public update can now point to something concrete: which behavior changed, why you changed it, which task someone can try, and what feedback would affect your next decision. Keep the request focused on that change.
On Buildside, founders share progress, questions, and lessons. I founded Buildside. It can provide context around a demo and its next iteration; the demo still needs its own reliable starting state. Don't assume that everyone who follows a founder is a likely customer or has time to run a full test.
Link the relevant update to a stable explanation of the demo. If you replace the demo version later, preserve enough context that an older comment still makes sense. Otherwise a good report can look impossible simply because the product changed underneath it.
Review the results before changing the product
Keep task observations apart from feature suggestions and general praise. A reproducible error may deserve an immediate fix. A suggestion for a different workflow needs more context about who needs it and why.
Record failed attempts as well as successful ones. If a visitor stopped because the sample was confusing, don't quietly label that a product failure. Repair the demonstration and run the task again. If the sample is clear and the same behavior still causes trouble, investigate the product path.
You can report a small result honestly: which version was tried, which task was attempted, what happened, and what you changed next. Avoid publishing a success percentage from a handful of informal attempts as though it describes your whole audience.
Before your next public demo, repeat the full path yourself twice and check it from a second session. Make the task, starting state, and reset behavior easy to understand. That gives the people helping you a fair chance to produce feedback you can use.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
Top comments (0)