For devs shipping alone

Feature Flag Software, Picked Without the Hype

Compare feature flag software by what a solo dev or small team actually needs, then scope a project worth putting behind a flag. Free, no signup.

Generate a project spec Compare the tools
Dark developer desk at night with a laptop and monitors showing code and a feature flag dashboard
What people hire it for

Four jobs a feature flag does

Ship dark, release later

Merge unfinished work to main behind a flag. Deploying code and releasing a feature stop being the same event, which makes Friday merges less scary.

Roll out gradually

Enable a feature for yourself, then 5% of users, then everyone. If error rates climb, you stop at 5% instead of apologising to all of them.

Kill switch in seconds

A flaky third-party integration or a slow query can be switched off from a dashboard. No rollback, no redeploy, no 3 am hotfix branch.

Test with real users

Serve two variants, measure one metric, keep the winner. Some tools bundle experimentation, others leave it to your analytics stack.

Compare

Four tools, honest differences

Pick on hosting model and license first. Pricing moves often, so confirm limits on each vendor's page before you commit.

CriteriaLaunchDarklyPostHogGrowthBookUnleash
LicenseProprietaryMITMITApache
Self-host optionNoYesYesYes
Free tierYes, capped on usageYes, 1M flag requests a monthYes on cloud, free to self-hostFree to self-host
Built-in experimentsYesYes, in cloudYesLimited
Best fitTeams that want a managed enterprise productTeams that also want product analyticsTeams that care about A/B testingTeams that need data sovereignty
Use case

Don't adopt a tool before you have a risky feature

The usual mistake is installing feature flag software on a project that has nothing worth flagging. A flag earns its keep when there is a change you would hesitate to ship to everyone: a payment flow, a data migration, an AI feature with unpredictable cost. If you can't name that change, a boolean in an environment variable is enough for now. The generator on whatshouldibuildnext.com turns a rough idea into a spec with a suggested stack and the one or two features that carry real risk, so you know what to put behind a flag before you pick a vendor.

  • Free, client-side, no signup
  • Names the features that are risky to ship
  • Suggests a stack that supports your flag SDK
Try the generator
Developer hands on a keyboard with a code diff on screen in a dim room
Hosting

Hosted or self-hosted: pick the smaller burden

Open-source feature flag tools are free in licence terms, not in time. Self-hosting means a database to back up, a service to keep alive and an upgrade path to follow, all for a system your production code now depends on at request time. Hosted tools remove that, and their free tiers are generous enough for most side projects. Choose self-hosting when data residency or per-request cost forces your hand, not because it feels more indie. Whichever you pick, code against OpenFeature so the choice stays reversible.

  • Hosted: no servers, usage-based pricing
  • Self-hosted: no request bill, you own uptime
  • OpenFeature keeps the vendor swappable
Notebook sketch of a release plan splitting into two paths next to a laptop
Getting started

From zero to a flagged feature

  1. 1

    Name the risky change

    Pick the one feature that could hurt you if it shipped broken. That is your first flag, not all twenty.

  2. 2

    Start with the free tier

    Create an account or spin up the open-source image locally, grab an SDK key and wire up one flag in a branch.

  3. 3

    Default to off

    Make the safe behaviour the fallback so a failed flag lookup never exposes unfinished code.

  4. 4

    Roll out in stages

    Yourself first, then a small percentage, then everyone. Watch errors and latency between each step.

  5. 5

    Delete the flag

    Once a feature sits at 100% and is stable, remove the flag and the dead code path in one pull request.

FAQ

Common questions

What is feature flag software?
It is a tool that lets you turn code paths on or off at runtime without redeploying. You wrap a risky change in a flag, ship it dark, then enable it for yourself, a percentage of users or everyone, and switch it off instantly if it breaks.
Do I need feature flag software on a solo side project?
Usually not on day one. A boolean in an environment variable covers a lot. Reach for a real tool when you need per-user targeting, gradual rollouts or a kill switch you can flip without touching a server.
Is there a free feature flag tool?
Yes. LaunchDarkly, PostHog, GrowthBook, Flagsmith and Statsig all list free tiers, and Unleash, GrowthBook, Flagsmith and PostHog have open-source editions you can self-host. Limits and prices change, so check each pricing page before you commit.
Should I self-host or use a hosted service?
Hosted means no servers to patch and flags evaluated for you. Self-hosted means no per-request bill and full data control, but you run the database and the uptime. For a side project, hosted free tiers are usually less work.
What is OpenFeature and does it matter?
OpenFeature is a vendor-neutral API for flag evaluation. If you code against it, switching providers later means changing a provider plugin, not rewriting every flag call. It is cheap insurance against lock-in.
How do I stop old flags from piling up?
Give every flag an owner and a removal date when you create it. Treat a flag that has been at 100% for a few weeks as debt: delete the flag and the dead branch of code in the same pull request.
What should I build to practice with flags?
Something with at least one feature you would be nervous to release to everyone. The generator on whatshouldibuildnext.com scopes a small project with a risky feature or two, which gives you a real reason to wrap code in a flag.

Scope something worth flagging

Free spec generator, client-side, no signup. Get the features and a suggested stack, then pick your flag tool.

Generate a project spec
~/build
Generate an idea