When you share a public demo of a feature behind a flag, state which environment and kind of account received the feature, what variation was enabled, and what you actually observed working. Then explain what an ordinary visitor can do today. A successful recording of a selected test account does not establish general availability.
For developers building in public, this is both a testing problem and a communication problem. The feature may be real while the access described by the post is misleading. A useful demo keeps its setup visible enough for a founder peer to understand the result, without exposing credentials, private identifiers or customer data.
Define the claim before you record the feature
Consider a fictional SaaS tool that groups imported support requests. Its founder has added a suggested category panel behind a feature flag. The next public update should show how that panel works and invite feedback on the category explanation. It should not imply that every customer already has the feature.
Write the intended claim first: a selected demo account can see and review category suggestions in the current preview build. That describes a bounded capability. Keep a separate sentence for availability: other accounts still see the existing manual categorization flow.
These statements answer different reader questions. The first explains the work being demonstrated. The second explains what someone arriving from the post should expect. If either statement is uncertain, verify it before publishing the recording or narrow the post accordingly.
Record the setup without publishing the secrets
Keep a private record of the application version, environment, test identity category, relevant flag variation and fixture data used for the recording. The public version usually needs a smaller description: preview environment, a test account explicitly included in the rollout, and fictional support requests.
Do not display an SDK key, targeting identifier, account email or a configuration page containing unrelated users. Showing that a flag exists is rarely the useful part of the product story. Show the reader the behavior and explain the relevant access boundary in plain words.
LaunchDarkly's testing guidance describes targeting as a way to serve variations to particular contexts. It also distinguishes fallback values used when evaluation cannot complete. Those are useful concepts for planning the demo, regardless of which flag system your product uses. They do not replace checking the application itself.
Check the selected experience and the ordinary experience
For the fictional support tool, first open the selected demo account and complete the intended task with fictional requests. Confirm that the suggested category appears, that its explanation is readable and that accepting it changes the request as expected. Record what happens after saving and reopening the item.
Then inspect an account that is outside the preview. Verify that it receives the intended existing workflow and that the public link does not promise access it cannot provide. A label saying preview is not enough if the page invites everyone to use a control that only selected accounts can see.
Keep these observations separate in your notes. A configured on state is evidence of configuration. Seeing a panel is evidence that it rendered. Saving a chosen category and reopening it is evidence about that specific journey. None alone proves that every account or every data shape behaves correctly.
Choose a small set of meaningful flag states
Do not turn a public demo into an attempt to exhaust every possible flag combination. Choose the states that matter to the current claim and known risks. For this example, those include the selected preview experience, the ordinary off experience and the intended fallback when evaluation is unavailable.
LaunchDarkly recommends a defined set of test scenarios, including current and upcoming production settings, fallback values and important problematic states. Apply that principle deliberately. The article's suggested checks are a focused demonstration plan, not a complete test strategy for every application.
If another flag controls a prerequisite, include it in the setup record. A category panel might depend on a particular import format or permission. Demonstrating one flag without noting that dependency could leave a peer unable to understand why their otherwise similar account shows something different.
Test fallback through your normal supported process
A fallback state is not just another screenshot. You need to understand which behavior the application serves if flag evaluation cannot complete. Use the supported test facilities and established environment for your system. Do not disrupt real customers or weaken access controls to produce a dramatic public example.
For the fictional product, the intended fallback might be manual categorization. The useful check is whether a tester can still complete that supported task and whether the interface explains the available route. If the application instead blocks the whole request list, the public update should not describe fallback as harmless.
Document the difference between a deliberately configured off variation and an evaluation failure. They may lead to the same visible result while exercising different paths. If you have only checked the off state, say that. Do not label an untested failure mode as verified recovery.
Make the demo explain its own availability
Put the access boundary close to the demonstration, where a reader can encounter it without opening another thread. A suitable hypothetical caption is: “This is the category preview in a selected test account. General accounts still use manual categories. The requests shown are fictional.”
Avoid a headline such as “Category suggestions are live” if the post never explains the restricted rollout. A more accurate title could name the preview and the question being reviewed. Specific wording lets you share real progress without converting a controlled test into a general launch announcement.
I build Buildside. Its public product description includes founders sharing progress and finding concrete help. A demo with a clear boundary gives peers useful context for feedback. It does not imply that Buildside tested your implementation or that a community response certifies the feature.
Ask peers about the part they can actually assess
The founder in this example wants feedback on the category explanation. Give a peer one fictional request, the suggested category and its stated reason. Ask what they think the suggestion means and what information they would need before accepting it. Keep that question distinct from whether they would buy the whole product.
If the peer cannot access the preview, provide an accurate recording or a safe test route you are authorized to share. Do not ask them to borrow another person's account. A reviewer watching a recording can assess what is communicated; they cannot verify an interaction they have not performed.
Record the review method beside the response. “Watched the recording” and “completed the task in the preview account” describe different evidence. That small distinction helps prevent a public discussion about wording from becoming an unsupported claim that the workflow has been validated.
Recheck the post when the rollout changes
After recording, compare the published caption and destination with the current rollout. If the feature opens to more accounts, update the availability statement where practical. If the preview closes, make the old post's status clear so a new visitor does not mistake historical access for a current invitation.
Keep the original observation honest. A later rollout does not retroactively prove the earlier demo covered all users. Likewise, a later bug does not mean the recorded test never worked. Date the evidence and describe which setup produced it.
For the fictional support tool, the finished update can show the selected journey, state the ordinary experience, name the review question and acknowledge what remains untested. That is enough to make the work understandable. The reader sees a feature in a defined state, and the developer keeps a useful record of what was actually checked.
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 (1)
The private setup record earns its keep on the failure you didn't mention: the flag config drifting after the recording. Six weeks later someone flips the rollout percentage or kills the flag, and the post still says preview works. A cheap guard is to date-stamp the public claim (as of Oct 2026, preview only) and keep a recurring check that the flagged path still renders for the test account, so the post and reality age together. Also worth one line in the demo: where the reader can verify the boundary themselves, like trying the feature logged out. That turns your access claim into something they can test instead of trust.