Feature Flags for Customer Targeting: Roll Out Features to the Right Users

Most feature flag tutorials treat rollout as a single dial: 0% to 100%, everyone gets the same thing. But real SaaS products don't work that way. Enterprise customers expect early access. Beta users signed up to see things first. Free-tier users shouldn't see a feature that's behind a paywall.

Percentage rollouts solve one problem — gradual exposure — but they don't solve targeting. You don't just want to control how many users see a feature. You need to control which users see it.

The Alternative Is Worse

Without targeting rules, teams reach for bad alternatives: feature branches that live for months, environment-specific builds, or config files that get out of sync between customers. Some teams build a bespoke "feature entitlements" system from scratch — then spend a year maintaining it.

All of this complexity already exists in a good feature flag platform. The key is passing the right user attributes at evaluation time and defining targeting rules against them.

Targeting Rules in Practice

The pattern is straightforward. When you initialise the SDK, pass a user context that includes the attributes you want to target on — plan tier, organisation ID, beta opt-in status, country, or anything else that matters to your product. The flag evaluation engine applies your rules server-side and returns the right variation for that user.

Here's how this looks using the Featureflow JavaScript SDK:

import featureflow from 'featureflow-client';

// Initialise with the current user's context
const client = featureflow.init(process.env.FEATUREFLOW_API_KEY, {
  key: user.id,
  attributes: {
    plan: user.plan,            // "enterprise" | "pro" | "free"
    betaOptIn: user.betaOptIn,  // true | false
    country: user.country,      // "AU" | "US" | ...
    orgId: user.orgId,          // specific org IDs for targeted pilots
  },
});

// Evaluate — targeting rules live in the Featureflow dashboard
if (client.evaluate('advanced-reporting').isOn()) {
  renderAdvancedReporting();
}

In the Featureflow dashboard you then define the rules: plan equals "enterprise" → ON, betaOptIn equals true → ON, everyone else → OFF. No code change required when you adjust a rule — update the dashboard and it propagates in seconds.

Three Targeting Patterns Worth Knowing

• Plan-based entitlements. Gate premium features behind a plan attribute. When a customer upgrades, they get access instantly — no redeploy, no support ticket to enable a flag manually.
• Opt-in beta programs. Let users self-select into early access via a UI toggle. Store the preference, pass it as an attribute, and the flag handles the rest. You can expand the beta cohort without touching code.
• Pilot rollouts per org. Target a specific organisation ID during a paid pilot. Once the pilot proves out, expand the rule to the full segment — or roll back cleanly if it doesn't.

Keep the Attributes Stable

One pitfall: if user attributes change shape between sessions (a renamed field, a null where a string used to be), your targeting rules silently break. Treat the attributes you pass to the flag SDK as a published contract — define a type, validate at the boundary, and version changes deliberately.

A small schema for your user context goes a long way toward keeping targeting rules predictable as the product grows.

Customer targeting turns feature flags from a deployment safety net into a product delivery tool. The same infrastructure you use to roll out cautiously also becomes the mechanism for gating features by plan, running betas, and managing pilots — without any of the custom entitlement code that usually accumulates around those workflows.

👉 See how targeting rules work in Featureflow — free to start, no credit card required.

#FeatureFlags#CustomerTargeting#UserSegmentation#ContinuousDelivery#SaaS