Introduction

feat is a feature flag platform. You define flags in the feat dashboard, your application reads them through one of the feat SDKs, and feat decides what value each user gets based on the rules you set.

What feature flags are for

A feature flag is a name in your code that resolves to a value at runtime. Instead of:

if (isCheckoutV2Enabled) {
  // new checkout
} else {
  // old checkout
}

shipping a release that flips the constant, you ship the code with the flag in place and decide who sees the new checkout from the dashboard, separately and at any time.

Teams use flags for three overlapping reasons:

• Decouple deploy from release. Merge code to main behind a flag that defaults off. Turn it on for one user, then a team, then everyone, without redeploying.
• Target individual users or groups. Show a beta to paying customers only. Roll a region-specific change out to one country. Pin a fix on for the customer hitting the bug.
• Stay safe. If something breaks in production, turn the flag off. No rollback, no rebuild.

How feat fits in

You hold three things:

• An organization in feat. Inside it you create projects, environments, and feature flags.
• One or more SDK keys scoped to an environment.
• Your application code, calling the feat SDK to read flag values.

The SDK fetches a small JSON file called the datafile from feat’s edge and keeps it in memory. Evaluation runs locally in your process. There is no network call per flag read.

┌────────────┐    polls datafile   ┌─────────┐
│ Your app   │ ◄────────────────── │ feat    │
│  + feat    │                     │ data    │
│  SDK       │                     │ plane   │
└────────────┘                     └─────────┘
        │
        │ getBooleanValue("checkout-v2", false, context)
        ▼
   evaluated locally, in microseconds

When feat is a fit

feat is built for product and platform teams that want:

• Flag values per environment, with proper isolation between staging and production.
• Targeting rules richer than “is this user in a list,” including segments, multi-attribute conditions, and percentage rollouts.
• Auditable changes: every edit is recorded with who made it and what changed.
• A path to OpenFeature compatibility so you are not locked in.

If you only need a single boolean toggle and have no users, feat is overkill. If you need experimentation with a statistics engine right now, see how feat compares in SDKs overview.

Where to go next

• Quickstart walks you from a fresh account to a flag your code can read.
• Core concepts covers the hierarchy and vocabulary in one page so the rest of the docs make sense.
• SDKs overview lists every client and links to its setup.