Gradual Feature Rollouts: Ten Percent of People, Companies or Requests?

Before asking a developer to release a feature to a percentage of customers, decide what a customer means. A person, a company account and a request are different units. For a shared business workflow, the wrong unit can leave colleagues looking at different versions of the same job.

A gradual rollout controls exposure to a change. It does not by itself prove that the feature is correct, replace access permissions or undo records already written. Treat it as an operational decision in your app brief, not merely a slider in an administration screen.

Choose the group before the percentage

Imagine a hypothetical repair portal introducing a new job-approval screen. If each individual is allocated separately, the requester might see the new screen while their approving colleague sees the old one. If the process must stay consistent within a customer company, ask the developer to assess company-level allocation instead.

The LaunchDarkly percentage rollout documentation provides a concrete product example. It describes assigning variations using a context key, with rollout logic based on the key and context kind. This is identity-based allocation, not a promise that the next set of page requests will contain an exact proportion of new screens.

Write down the chosen identity and where it comes from. Ask what happens before sign-in, on another device, after a company switch and when an expected identity is missing. Do not invent replacement identities merely to make the feature appear to work. Specify a deliberate supported outcome for those cases.

Keep related changes together deliberately

Suppose the new approval screen requires a new attachment view. Giving both flags the same percentage does not necessarily give both features to the same customers. LaunchDarkly explicitly says different flags allocate contexts independently, even with matching rules and percentages. Its documented way to target the same set is to use a segment.

Ask for one coherent exposure rule for changes that depend on each other. That could be a shared cohort or a single release decision, depending on the implementation. The requirement is that a customer cannot enter a new workflow and then lose a required step because another independently allocated flag says no.

Do not interpret a small observed group as an exact census quota. Ask the developer to explain how the chosen allocation behaves for your actual population. Separately agree how you will confirm who received which version when support investigates a problem.

Define the missing-identity and off paths

A default-looking configuration is not enough evidence of a safe fallback. LaunchDarkly documents a particular edge case: when a matching context has a different kind from the rollout kind, it can receive the first configured variation with a positive percentage, which may not be the default. This is a product-specific warning to test the actual rules, not a statement that every flag system behaves that way.

Your acceptance check should cover an eligible account, an excluded account and the unexpected identity case. Check both the visible screen and the permitted server action. A hidden button must not become the only protection for a restricted operation.

Agree what disabling the change means for work already started. Can a customer finish an approval that began in the new version? Will the old screen understand the saved record? Ask for a separate compatibility or reconciliation plan where needed. Do not label a display switch as a database rollback.

Give expansion and stopping a named owner

Choose who may increase exposure, what observations they review and which problems require pausing. Include both technical failures and whether customers can finish the intended task. More enabled accounts is not evidence of better business outcomes, and a rollout without a suitable study does not establish that one version caused an improvement.

Rehearse expansion and stopping in an isolated environment using controlled accounts. Record the selected identity, linked-feature grouping, support visibility, in-progress behavior and decision owner in the requirements for your web app. A useful gradual release is one your team can explain and stop coherently, not simply one that begins with a small number.