Feature Flags for a Small Team, Without the Enterprise Overhead

Feature flags used to be an enterprise concern. Now they're standard practice on any team that ships to real users, including two-person startups. But most feature flag advice is written for platform engineering teams at 500-person companies. This post is what actually works for a small team of engineers using feature flags to ship safely.

At Augere Labs we set up flags on every project past the MVP stage. Below is the setup we recommend, the flag types worth knowing, and the pitfalls that turn flags into tech debt.

What flags actually do for a small team

The pitch is "flags let you separate deploys from releases." True. But at a small startup, the specific wins are more concrete.

You can ship a half-built feature to main branch without it going live. You can turn a feature on for one customer to test. You can kill a broken feature without redeploying. Any of these on their own is worth the setup cost.

The four flag types worth knowing

Not all flags are the same. Mixing them up is where the tech debt starts.

Release flags

Short-lived flags that gate a new feature during rollout. On for internal team, then beta users, then everyone. Deleted within a few weeks of full rollout. These are the most common and least dangerous.

Kill switches

Long-lived flags that let you instantly disable a feature that's misbehaving. Different from release flags — you keep these alive after launch as insurance. Every AI feature we ship has one, because model providers occasionally go down.

Permission or plan flags

Flags that gate features by user plan or role. "Analytics is on for Enterprise customers." These aren't really feature flags — they're entitlements. Treat them differently. They live forever and belong in your billing logic, not your flag tooling.

Experiment flags

A/B test flags. Randomize users into groups, ship different experiences, measure results. Powerful when done right, expensive when not. Small teams rarely have the traffic to run real experiments; treat this as advanced.

The tooling question

You don't need LaunchDarkly to ship flags. For most small teams, the right answer is boring.

Just a database column

Add a boolean column to your feature or user table. Read it at request time. Done. This is what most startups actually need for their first ten flags. Zero external dependency, zero cost, works offline in tests.

An environment variable

For flags that flip once and stay — "use new payment provider" — an env var is fine. Change it, redeploy, done. Not fancy, works everywhere.

A managed service

LaunchDarkly, Statsig, PostHog Feature Flags, or Unleash. Worth it once you have 20+ active flags, non-technical people who need to toggle them, or real experiments with traffic. Below that threshold, the tooling is more work than the problem.

PostHog is a common choice for small teams because it bundles flags with analytics. Statsig has a generous free tier. Both are cheaper than LaunchDarkly for small deployments.

The setup we recommend for a small SaaS

Start with a database table. Two columns: a flag key and a JSON payload of who it's enabled for. A shared helper function reads it and returns true or false for a given user.

Cache the flags for a minute in memory. Flags rarely change every second, and cache saves a database hit on every request. Invalidate on flag update if you need faster propagation.

Wrap the read in one function that every service calls. Do not scatter raw database queries throughout the code — you'll regret it the first time you need to add logic like "always on for internal users."

This setup takes a couple hours to build. It scales to about 30 flags before you feel like migrating to a managed tool.

Practices that keep flags healthy

The failure mode isn't setting up flags. It's maintaining them.

Delete flags when they're done

Every flag has an expiration date. Release flags should die within two to four weeks of full rollout. If you never delete them, the codebase fills with dead conditionals and every new engineer has to figure out which branch is live.

Put a monthly reminder in your calendar to audit flags. It sounds neurotic; it's not.

Name flags for the change, not the code

Good: new-onboarding-flow. Bad: fix-signup-bug-2. Names are read by non-engineers eventually. Make them describe what changes when the flag flips.

Default to the new behavior

When you're rolling out a feature, the flag defaults to off. When rollout is complete, the flag defaults to on. When it's time to delete the flag, the old code path is removed. Don't skip that last step or you'll ship the old code by accident three months later.

Test both branches

If a flag is live, both sides of the conditional need tests. This sounds obvious. Teams skip it because the "off" branch feels safe. It isn't — it's the fallback when the flag breaks.

Mistakes that turn flags into tech debt

Using flags for permanent behavior. Flags are for temporary conditionals during rollout. Permanent behavior belongs in configuration, not a flag. If your flag has been on for a year, it's not a flag anymore — refactor.

Nesting flags. A flag inside a flag inside a flag. Each combination is a code path to test. Two nested flags create four paths. Four create sixteen. Keep the tree flat.

Flags without ownership. Every flag should have a person's name attached. Otherwise flags outlive the engineer who created them and nobody knows if they can delete.

Testing in production without a flag. Rolling out a feature to everyone at once and hoping it works. Flags exist so you don't have to do this. Use them.

Trade-offs to be aware of

Flags aren't free. They add complexity to reasoning about the code. A function with three flags has eight possible behaviors, and only one of them is what's actually running for most users.

Flags also affect performance. Every check is a lookup, and if you're not caching, that's a database call per request. Cache aggressively.

And flags can mask bugs. If a feature only works when a specific flag is set, and the flag is on for internal users but off for real ones, you'll ship a broken feature and not know until a customer reports it. Test with the flag in the same state real users see.

How flags fit with AI features

AI features benefit from flags more than any other kind of feature. Model providers have outages. Prompt changes cause regressions. New models look better in staging and worse in production.

Every AI feature we build ships with at least two flags: an on/off kill switch, and a model selector that lets us swap providers without a deploy. Our AI observability post covers what to monitor once flags are in place.

Common misconceptions

"Feature flags are overkill for a small team." They're overkill until the first time you need to disable a broken feature at 11pm on a Friday. Then they're the cheapest tool you own.

"We need a proper flag service before we can start." You don't. A database column and a helper function work for the first year of most startups.

"Flags will slow us down." They speed you up. You can merge to main confidently, ship half-built features safely, and roll back without a deploy.

Frequently asked questions

Final note

Feature flags are unglamorous infrastructure that pays for itself on the first bad deploy. Set them up before you need them, use them consistently, and delete them when they're done. That's it.

If you're setting up your first flag system and want a review of the design before you ship, book a call. We'll walk through the pattern and tell you where it'll break first.