Liteguard

Appearance

Guarding Pattern: New Feature ​

This pattern covers the earliest phase of shipping a new feature: protecting it behind a guard from the moment you write the code, so you can deploy safely without the feature being visible to anyone until you are ready.

When to use this pattern ​

Use this pattern when:

  • You are building something that is not ready for users yet but you want to merge and deploy the code.
  • You want to test the code path in production with a small internal audience before a wider release.
  • You want a simple kill switch you can flip if something goes wrong after release.

Step 1: Wrap the feature in a guard check ​

In your application code, wrap the new feature's entry point in an isOpen call. Choose a guard name that clearly identifies the feature. A dot-separated convention keeps related guards grouped in the catalog.

ts
if (client.isOpen('feature.new_dashboard')) {
  renderNewDashboard();
} else {
  renderLegacyDashboard();
}

Use a guard name you will recognize in the Liteguard UI. The name does not need to exist in Liteguard before you deploy — the SDK will record it as an unadopted guard the first time it is evaluated.

At this point the feature is off for everyone because unadopted guards return false by default.

Step 2: Deploy ​

Deploy the code. The guard call starts being exercised in production but the feature remains invisible because the guard returns false. No users see anything different. The guard begins appearing in the Liteguard guard catalog as an unadopted guard.

Step 3: Create the guard in Liteguard ​

Open the Guards tab. If the guard has been evaluated at least once, it appears in the catalog under the unadopted section. Click Adopt next to it. The metadata modal pre-fills the guard name from what the SDK reported.

If the guard has not appeared yet (for example, the code path has not been hit), click Add at the top right of the catalog instead and type the name exactly as it appears in your code.

In the metadata modal:

  • Confirm the name is correct.
  • Add an optional description to explain what the feature is.
  • Leave the lifecycle state as Active.
  • Click Save.

After saving, Liteguard opens the guard detail page.

Step 4: Set the default behavior ​

On the guard detail page, the environment configuration section shows the current state for the selected environment.

Set the Default value toggle to off (false). This means the feature remains hidden for all users in this environment until you add a rule that opens it for someone.

Click Save.

Step 5: Enable for internal testing ​

To expose the feature to a specific user or a set of users for internal testing, add a rule.

In the Rules section, click the add button and configure a rule:

  • Property name: userId (or whatever identifier your application passes to isOpen)
  • Operator: in
  • Values: the IDs of the internal testers, one per line
  • Result: true (on)

Make sure the rule is Enabled, then click Save.

The feature is now visible to only those user IDs. Everyone else still sees the default value of false.

In your SDK call, make sure you pass the property:

ts
if (client.isOpen('feature.new_dashboard', {
  properties: { userId: currentUser.id },
})) {
  renderNewDashboard();
}

Step 6: Verify in the guard catalog ​

After internal testers exercise the feature, return to the Guards tab. The guard's Evaluated count and Last evaluated time on the catalog card confirm that the SDK is calling the guard. Open the guard detail page to check the rule configuration looks as expected.

If you want to confirm exactly what the SDK is receiving, open Config > [workspace] > [project] and expand the Bundle Preview section. It shows the assembled guard configuration for the selected environment, including your default value and rules.

What comes next ​

Once internal testing is complete and you are ready to release more broadly, see Release a Feature for the optional staged rollout and full-release steps.

If the feature is never going to launch, set the guard's default value to false, remove any open rules, disable the guard's lifecycle (archive it), and leave a note in the description for future reference. The guard stays visible in the catalog in its archived state.