Build in Public
Share a SaaS Rollout Without Overstating Access
Explain who can use a new SaaS feature, distinguish enabled access from use, and follow up when a staged rollout expands or pauses.
By Uriel Bitton · · 9 min read
The short answer
When sharing a staged SaaS rollout in public, say who can use the feature now, how access is enabled, and what other readers can do next. Verify the customer task and name the population behind any percentage. Keep the public availability note current when access expands or pauses.
When sharing a staged SaaS rollout in public, say who can use the feature now, how access is enabled, and what everyone else can do next. Put those limits beside the announcement. A demo, a deployed release, and a customer’s ability to complete the task can each be at a different stage.
Building in public gives you room to show the work before access is broad. Explain why you chose a small first group, what you are checking, and what would justify expanding it. Readers can follow that decision while customers can tell whether the update applies to their account.
The method below connects a public update to a private record of actual availability. It includes a fictional event-registration SaaS, sample announcement copy, and a later pause. All product details and figures in that example are invented. No customer rollout or feature-flag test was performed for this article.
Start with the access a reader can verify
Write the opening around a customer task. “Workspace managers in our first pilot group can preview a badge layout on the web” gives an eligible reader a way to recognize the feature and try it. A general statement that badge previews have shipped leaves several questions unanswered. Which workspaces? Which role? Which app? Is there an invitation or an extra setting?
Deployment and release can happen separately. A team can put code into its production environment while controlling who receives the new behavior. LaunchDarkly’s official guide explains how feature flags support that separation and several gradual release patterns. For a public founder update, the practical implication is to verify customer access before describing what customers can do. LaunchDarkly’s deployment and release guide
Keep the condition in the sentence that makes the claim. Someone sharing a screenshot or quoting your opening may leave the rest of the post behind. If you say the feature is available to pilot workspaces, that qualification should travel with the feature name. A footnote at the bottom is easy to lose.
A limited rollout can still support a useful public story. Show a sanitized example, describe the product decision, and say which uncertainty you are working through. Save the invitation to try it for readers who can actually take that step.
Record eligibility, enabled access, and use
Before drafting, check three separate facts. Eligibility describes the group allowed to receive the feature under the current plan. Enabled access describes who has received it. Use describes who attempted or completed the relevant task during a defined period.
For a small rollout, a private note might contain the following.
Current scope. Name the plan, workspace type, region, device, version, or invitation status that affects access. Include only conditions that apply.
Enablement. Record whether access is automatic, manually assigned, or something an administrator must turn on. Check any required permission.
Observed task. Record what you verified from the reader’s path and when. Keep enabled accounts separate from accounts with recorded use.
Next decision. Name the check that would support expansion, the person responsible for it, and when you will report again.
Use this note to produce the public wording. You can keep individual account identities and detailed targeting logic private. The reader needs enough information to understand their own access and the state of the work.
Check the path with the role you plan to address. An internal administrator seeing a feature gives you evidence about that account. It leaves the workspace manager’s path unverified. If you cannot check a relevant condition before posting, narrow the announcement to what you have verified.
Name the unit behind every rollout percentage
A percentage needs both a population and a unit. “25% of workspaces in the pilot” and “25% of signed-in users” describe different access patterns. In a product with several people per workspace, switching those units can change what readers think their whole team will see.
LaunchDarkly’s percentage-rollout documentation describes allocation using context kinds and keys, including user and organization contexts. Its rollout logic assigns contexts through hash buckets. A configured allocation percentage describes that mechanism. A public claim about the number of real workspaces with access still needs an observation of those workspaces under the applicable rules. LaunchDarkly’s percentage-rollout documentation
If all you have checked is the configuration, describe the planned allocation and name its unit. If you have checked actual enabled workspaces, give the observed count and its denominator when those figures are safe to share. A small pilot is often easier to explain in raw counts than in a percentage.
A fictional badge-preview rollout
Imagine a founder building an event-registration SaaS with 240 paying workspaces. They have invited 12 workspaces into a pilot for a new badge-layout preview. All 12 have agreed to take part. The first release is limited to workspace managers using the web app. Printing from a mobile device is outside this release.
The founder manually enables the feature for three of those workspaces. At the time of the public update, all three can open the preview, and two have recorded a completed preview task. The founder wants to understand whether managers can recognize a misplaced field before sending badges to print.
Here are the counts behind the update.
Eligible pilot workspaces are 12.
Workspaces with the feature enabled are three.
Enabled workspaces with a recorded completed preview are two during the stated observation period.
Total paying workspaces are 240.
Three divided by 12 is 25% of the eligible pilot. Three divided by 240 is 1.25% of all paying workspaces. Those calculations describe the same enabled group against different populations. Saying that a quarter of customers have access would overstate the release.
Even within the pilot, enabled access and recorded use answer different questions. Two completed previews show that two workspaces completed the defined task during the observation period. That count alone gives the founder no basis to claim that the feature reduced misprints or improved event operations.
A public update with the conditions intact
The following is proposed copy for the fictional rollout.
As of June 4 at 10:00 UTC, workspace managers in three of our 12 invited pilot workspaces can use badge-layout previews on the web. We’re starting with a small group to check whether managers can spot a misplaced field before printing. Mobile printing is outside this release. Other workspaces can watch the sample-data demo, and invited pilot managers can contact us if the preview is missing. We’ll report on the first task checks on June 7 before deciding whether to expand access.
This copy gives current users a task and a route for an access problem. It gives other readers a way to follow the work. It also commits to a dated report that the founder controls. Expansion remains a decision tied to evidence.
A screenshot accompanying the post should match the stated environment. Use sample data and identify the view as the pilot web experience in its caption. If the demo was recorded earlier than the access check, give its recording date when that difference matters. Keep the description of what readers can do today anchored to the current check.
Choose a next step for each audience
A public rollout update can reach existing customers, invited testers, potential buyers, and fellow founders. Give each relevant group a route that matches its position.
An enabled customer can receive the task and a help link. An invited customer awaiting enablement can receive the expected next contact and a way to ask about access. A prospective customer can see a demo with the limitations intact. A peer can discuss the decision you are working through without being encouraged to hunt for a feature they cannot use.
If you want more testers, publish a separate invitation with the criteria, activity, time commitment, and selection process. Link it from the progress update when it is open. Buildside’s guide to writing a public SaaS beta invitation develops that recruitment task. Expressing interest and receiving access should each have a clear meaning.
Do not promise a wider release date just to make the public post feel complete. You can promise the next progress report if you can deliver it. Give the condition for the next release decision in plain language, such as checking that invited managers can open and complete the preview task across the supported layouts.
Explain a pause in the same public record
Suppose the fictional founder finds that one supported badge layout clips a long name. They keep the pilot at three workspaces while working on the layout. The issue changes the next decision, so it belongs in the rollout history.
A follow-up could say that expansion is paused while the long-name layout is corrected, identify the affected preview condition, and tell enabled managers what to do. If the feature is temporarily disabled, say that explicitly and provide the current route. If existing access continues, state the relevant limitation and available workaround only after checking them.
Date the follow-up and make it easy to find from the original update. Keep a short description of the earlier state so someone reading the sequence can see what changed. A person arriving from an old social post should reach the current availability information.
When access expands, report the new scope and repeat the customer check. Reaching all invited pilot workspaces still leaves the other paying workspaces outside that pilot. A later announcement about broader access needs its own verified population and next steps. Buildside’s guide to using a public SaaS changelog after release explains how to connect ongoing changes to customer use.
Define your release labels in ordinary language
Words such as preview and beta need an explanation of the actual offer. GitHub’s October 2024 terminology change explained that whether a preview was publicly announced distinguished its public and private labels. Its current feature-preview documentation also describes account controls for enabling and disabling available previews. Those are GitHub’s documented practices, and they show why a label alone cannot answer every access question. GitHub’s preview terminology announcement, GitHub’s feature-preview documentation
Use a short sentence to define what your label means for this feature. Include relevant access, support, data, or workflow limits that you have established. Apply that wording consistently in the demo caption, announcement, help page, and invitation.
Before publishing the next installment, open the update as a customer would. Follow the task, check the access condition, and compare the result with your first sentence. Revise the claim until that reader’s experience supports it.
Questions founders ask next
Do I need to publish my feature-flag rules?
Share the conditions customers need to understand their access. You can keep account identifiers, internal targeting details, and operational controls private. A clear public scope statement can explain the rollout without exposing its implementation.
What if the announcement field is too short for all the limits?
Include the most important access condition in the short announcement and link to the maintained availability note. Use the longer note for the supported environment, next steps, and dates. Avoid a broad headline whose meaning depends on a qualification readers cannot see.
How should I describe a rollout chosen by individual user?
Name individual users as the allocation unit and check the experience for the roles you address. If colleagues in one workspace can receive different access, explain that where it affects the task. Report workspace-wide availability only after verifying it.
Sources
Frequently asked questions
Do I need to publish my feature-flag rules?
Share the conditions customers need to understand their access. You can keep account identifiers, internal targeting details, and operational controls private. A clear public scope statement can explain the rollout without exposing its implementation.
What if the announcement field is too short for all the limits?
Include the most important access condition in the short announcement and link to the maintained availability note. Use the longer note for the supported environment, next steps, and dates. Avoid a broad headline whose meaning depends on a qualification readers cannot see.
How should I describe a rollout chosen by individual user?
Name individual users as the allocation unit and check the experience for the roles you address. If colleagues in one workspace can receive different access, explain that where it affects the task. Report workspace-wide availability only after verifying it.
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.
Keep reading
How to Write a SaaS Beta Invitation While Building in Public
Write a public SaaS beta invitation that explains the user, task, effort, and limits. Screen for relevant experience and follow interest through to completed testing.
How to Use a Public SaaS Changelog to Drive Feature Adoption
Turn SaaS releases into useful build-in-public updates. Show the user problem, the shipped change, how to try it, and what customer behavior to check afterward.