Feature flags, for solo SaaS founders

A feature flag (sometimes called a feature toggle) is a runtime configuration value that turns a code path on or off without redeploying the application. The simplest form is a boolean check around new code:

// new-checkout-flow.ts
if (await flags.isEnabled('new-checkout', { userId })) {
  return renderNewCheckout();
} else {
  return renderOldCheckout();
}

The flag value lives outside your code — in a config file, a database, or a hosted service — so flipping it doesn't require a deploy. That single property is what makes flags useful for everything below.

What feature flags solve

Three concrete problems, in roughly the order a solo founder hits them:

1. Kill switches for risky features

You ship a new payment provider. It seemed fine in staging. At 2 AM your error-tracking lights up because of an edge case in their webhook signature validation. With a feature flag, you flip use-new-payment-provider to false and traffic routes back to the old provider. Without one, you're rolling back a deploy at 2 AM, which takes longer and leaves a worse paper trail.

2. Gradual rollouts

Instead of shipping a new feature to 100% of users at once, you ship it to 1%, then 10%, then 50%, then everyone. If error rates spike at 10%, you stop. This is sometimes called a canary release or progressive delivery. Most modern flag tools do this with a percentage slider tied to a hash of the user ID, so the same user always gets the same experience between page loads.

3. A/B testing

Show variant A to half your users and variant B to the other half. Track which one converts better. The flag determines who sees what; an analytics tool measures the outcome. This is the use case most often confused with experimentation tools, but it's just a feature flag wired up to an event log.

Types of feature flags

Pete Hodgson's canonical Martin Fowler essay on feature toggles categorizes flags into four types, which is the taxonomy most teams have adopted:

• Release flags — Short-lived flags that control whether new code is active in production. Removed once the feature is fully rolled out.
• Experiment flags — Used for A/B testing. Each user is consistently bucketed into a variant. Removed once the experiment concludes.
• Ops flags — Operational kill switches. Long-lived. Used to disable expensive features under load or quickly turn off broken integrations.
• Permission flags — Long-lived flags that determine which users see which features (e.g., beta-only features, paid-tier features). These overlap with entitlement systems and arguably belong outside flag tooling.

The categorization matters because the lifecycle is different for each. A release flag should live for days or weeks. A permission flag will live for years. Mixing them in a single tool is fine, but mixing the lifecycles in your head is how you end up with a codebase full of dead flags from 2023.

Tools that ship feature flags for solo founders

The market is bigger than it should be for what is fundamentally a key-value store with a UI. Four options that cover most solo-founder use cases:

Tool	Free tier	Best for	Catch
PostHog	1M flag evaluations/mo	Founders who already use PostHog for analytics	Self-hosting is non-trivial
LaunchDarkly	14-day trial only	Teams with a budget and complex targeting needs	Pricing is enterprise-coded
Unleash	Open source, self-host free	Privacy-focused founders OK with running infra	You operate it
Statsig	1M events/mo	Founders who lead with experimentation	UI optimized for experiments, not ops

For a solo founder, the right answer is almost always PostHog if you're already using it for analytics. The flag system is good enough, the SDK is small, and you avoid running yet another vendor. If you're not on PostHog, Unleash is the cleanest open-source option and Statsig has the most generous free tier among hosted experimentation-first tools.

You can also build your own flag system in a few hours. A row in your database with flag_name, enabled, and a percentage column gets you 80% of what these tools offer. It just won't have a UI for non-technical teammates — not a problem if there are no non-technical teammates.

Common feature flag mistakes (and how to avoid them)

1. Leaving dead flags in your code forever. Once a feature is fully rolled out, the flag check is dead weight. Schedule cleanup. Some tools warn you when a flag has been at 100% for > 30 days — turn that on.
2. Flagging things that should be config, and vice versa. If "AWS region" depends on the deployment target, that's an env var, not a flag. If "show new dashboard" depends on the user, that's a flag, not an env var. The split sometimes drifts.
3. Caching evaluations too aggressively or not at all. A naive setup hits the flag service on every request. A naive cache caches the user-A-saw-variant-B decision globally. The right pattern is to evaluate once per request, scoped to the user.
4. Using percentage rollouts without consistent bucketing. If your hash function depends on a session ID, the same user can flip between variants on every page load. Bucket on a stable user ID.
5. Treating flags as a substitute for testing. A flag lets you turn off broken code quickly. It does not replace running tests before merge. Founders who lean on flags as their safety net ship more bugs, not fewer.

FAQ

Related reading on this site

• PostHog review — the analytics tool that doubles as a flag system
• Solo founder tech stack — where flags fit in the broader picture
• Best AI tools for solo SaaS founders — the toolchain context