Skip to content
Innopulse Consulting
SaaS & engineering

What are feature flags?

Short definition

Feature flags are switches in code that turn features on or off at runtime without redeploying. They separate shipping code from releasing a feature and enable gradual rollouts, tests with individual customers, fast switch-off when errors occur and features per plan or tenant.

In many teams a deployment equals a release: as soon as code is live, all users see the new feature. Feature flags break that coupling. Code can ship before a feature is visible, and become visible to whom and when you choose.

Types of flags

Release flags hide unfinished features until they are ready and are removed afterwards. Experiment flags compare variants. Operational flags serve as kill switches to turn off a faulty or expensive feature immediately, such as an AI feature with exploding costs. Permission flags enable features per plan, tenant or user group and are often permanent.

Gradual rollouts

A new feature is first enabled internally, then for individual pilot customers, then for a percentage of users, finally for everyone. If observability data shows problems, you switch back without rolling back code. That lowers the risk of every release and allows more frequent deployments through the CI/CD pipeline.

Implementation in SaaS

The simplest form is a configuration per tenant in the database, evaluated server-side. For more complex rules there are services and open standards such as OpenFeature. Flags must be checked server-side when they control access to data or functions; a feature merely hidden in the frontend is not a protected feature. With multi-tenancy, the flag state belongs to the tenant, not to a single browser.

Flag debt

Every flag is a branch in the code and therefore a test variant. Release flags not removed after rollout accumulate and make code hard to follow. What works: an expiry date or an owner per flag and regular clean-up. Permanent permission flags, by contrast, belong properly in the model of plans and permissions.

When they pay off

Even small teams benefit from a kill switch for risky features and from pilot releases for individual customers. A full experimentation framework only pays off with enough users for meaningful comparisons. For a new product, a table of flags per tenant, checked properly server-side, is often enough — we build that into our SaaS launch packages from the start.

SaaS & engineering is our specialty

Innopulse doesn't just explain terms — we put them into practice for DACH companies.