Feature Flags

Turn features on by plan, or for the users you pick.

Workspace flags follow the plan a workspace pays for, and user flags follow the people you choose for a beta. Your app wraps UI in a component with the flag's slug, and changing who sees it is a console edit that lands on the next page load, not a deploy.

Your app is an organization in BuildBase. Your users sign in and work inside workspaces - one per team or customer.

You set up

In the console and the SDK

  • Features switched on by plan, so paying customers see them
  • Beta features for the users or lists you choose
  • Which switches workspace admins may flip themselves

Your users get

Inside their workspace

  • The features their plan includes, and nothing it does not
  • Early access when you add them to a beta
  • A settings screen where admins turn allowed features on or off

Flags that know about plans and people

The plan decides workspace flags and the console decides user flags. Your code only asks by slug.

Features by Plan

Link a feature to a plan and it turns on when a workspace subscribes. A workspace that stops paying loses paid features.

Betas for Chosen Users

Turn a feature on for specific users, lists or tags. Who is in the beta is set in the console, not in code.

Wrap and Forget

Wrap part of your app with the feature's name. It shows when the feature is on and hides when it is off.

Let Admins Choose

Mark a feature as something admins can switch, and it appears on their settings screen.

Early Access for One Customer

Turn a feature on for a single workspace from the console, for the customer you promised it to.

No Deploy to Change

Who sees what is a console change. Users get it on their next page load.

Wrap the UI, name the flag

The components read flags that already came down with the session. updateFeature() is there when admins should flip one themselves.

components/dashboard.tsxTSX
import {
  WhenWorkspaceFeatureEnabled,
  WhenWorkspaceFeatureDisabled,
  WhenUserFeatureEnabled,
} from '@buildbase/sdk/react';

function Dashboard() {
  return (
    <>
      <WhenWorkspaceFeatureEnabled slug="advanced-analytics">
        <AdvancedAnalytics />
      </WhenWorkspaceFeatureEnabled>

      <WhenWorkspaceFeatureDisabled slug="advanced-analytics">
        <p>Upgrade to unlock analytics.</p>
      </WhenWorkspaceFeatureDisabled>

      <WhenUserFeatureEnabled slug="beta-editor">
        <NewEditor />
      </WhenUserFeatureEnabled>
    </>
  );
}
components/digest-setting.tsxTSX
import { useSaaSWorkspaces } from '@buildbase/sdk/react';

// 'weekly-digest' is a user-managed workspace flag
export function DigestSetting() {
  const { currentWorkspace, updateFeature } = useSaaSWorkspaces();
  if (!currentWorkspace) return null;

  const on = currentWorkspace.features['weekly-digest'] ?? false;

  return (
    <label>
      <input
        type="checkbox"
        checked={on}
        onChange={() =>
          updateFeature(currentWorkspace._id, 'weekly-digest', !on)
        }
      />
      Weekly digest
    </label>
  );
}

Frequently Asked Questions

What people ask about Feature Flags.

Do my users see this?

Yes. They see the features their plan or beta includes, and workspace admins can switch the ones you allow from their settings screen.

How fast does a change apply?

On the user’s next page load or session refresh. There is no deploy.

Are percentage rollouts or A/B tests supported?

No. You target specific users, lists or tags, or tie a feature to a plan. There is no percentage rollout or experiment analysis.

What happens when a workspace stops paying?

In a canceled, unpaid or suspended workspace, plan-tied features fall back to their default, so it does not keep paid features.

Put your next feature behind a flag

Create the flag in the console, link it to a plan or a beta list, and wrap the UI in a component. Changing who sees it after that is a console edit.

7-day free trialNo credit card requiredCancel anytime