Feature Flags Explained:Ship Dark, Launch on a Switch
Feature flags explained: ship features dark, launch them by flipping a switch, and roll them out to 10% of users first — no redeploy, no launch-day panic.
Feature flags explained: a feature flag is an on/off switch stored in your database instead of your code: the feature ships to production dark — deployed but invisible — and you launch it later by flipping the switch for one beta customer, 10% of users, or everyone. No redeploy, no code change, no launch-day panic.
For a solo founder, flags are the difference between "launch" being a terrifying deploy and "launch" being a decision you make over coffee. Here's how they work, the four ways you'll actually use them, and the mistakes that make them backfire.
Feature flags explained: what a feature flag actually is
Without flags, controlling who sees a feature means editing code. The classic hack looks like this: "if the user's email ends in the beta customer's domain, show the new feature." Every change to that rule is a code change, and every code change is a deployment. Configuration lives in five different places, nothing has an audit trail, and the person who can flip the switch is whoever knows where the hack lives.
A feature flag moves that decision into data. The flag is a named switch — "new_dashboard: off" — stored in your settings system next to things like timezone and theme. Your code asks one question: is this flag on for this user? Change the answer in a dashboard, and the product changes behavior instantly — no deployment required. Flags sit in the same hierarchy as the rest of your settings: a global default, overridable per organization, overridable per user.
Ship dark, launch on a switch
The big mental unlock is that deploying and launching are two different events, and flags are what separate them.
Deploying means your code reached the server. Launching means users can see it. Without flags, they're the same moment — which is why launches feel dangerous, and why founders sit on finished work for weeks waiting for the "right" day. With flags, you deploy the feature half-built, dark, ten times if you like. It rides along with every release, tested in production, visible only to you. When it's ready, launch is a switch — and if deploying still scares you, this is the pattern that removes most of the fear.
It also changes your marketing. When launching costs nothing, you stop betting everything on one big day and start shipping a stream of small, flag-gated releases — the engine behind micro-launches.
The four ways founders actually use flags
| Use | What it looks like |
|---|---|
| Beta access | Turn a feature on for specific organizations only — your friendliest customers test it first |
| Gradual rollout | Enable for 10% of users, watch for errors, then widen to everyone |
| A/B testing | Half your users see version A, half see version B — the data picks the winner |
| Kill switch | A feature misbehaves in production — flip it off in seconds while you fix it calmly |
Notice these are product and marketing tools as much as engineering ones. Beta access is a sales conversation ("want early access?"). Gradual rollout is risk management. A/B testing is pricing-page optimization. The kill switch is sleep insurance.
12 weeksYour corporate career was never the planApply to the Solopreneur Accelerator.Apply now →The 2:47am argument for flags
A true story from my own production system: 2:47am, my phone buzzes with an error-rate alert. Endpoint failing, users affected. Two options — debug half-asleep, or roll back to the previous version in two clicks. I rolled back. Fixed in 90 seconds, back to sleep, debugged it properly in the morning.
A rollback is a blunt instrument: it reverts everything in that release — the broken feature and the three good ones that shipped with it. A feature flag is surgical. If the broken thing is behind a flag, you switch off just that feature and leave the rest of the release running. Best case, you never face the 2:47am choice at all: the gradual rollout meant only 10% of users ever saw the bug, the flag went off, and most of your customers never knew anything happened.
The mistakes that make flags backfire
- No default value. You add a new flag but never define what it means for existing users — they get an undefined answer and the app misbehaves in ways you can't reproduce. Every flag ships with an explicit default.
- No audit trail. The product suddenly behaves differently and nobody knows who flipped what, or when. Every flag change should record who, what, old value, new value, timestamp — flags without history are a debugging nightmare.
- Anyone can flip anything. Flags are production controls. Changing an organization-level flag should require admin permissions, exactly like changing the organization's billing.
- Checking the flag with a database query on every request. Flag checks happen constantly; they must come from a cache that refreshes when the flag changes, not from a fresh query every time a page loads.
Do you need flags from day one?
Earlier than you'd think. You don't need a fancy flag product — a flags table in your own database, managed from a simple admin screen, is the pattern that powers this at any scale. It's part of your settings system, which AI builds quickly from a good specification; the flag machinery itself is a few hours of work, not a project.
The payoff starts with your very first scary feature. The first time you ship something dark on a Tuesday, test it in production all week, and "launch" it on Monday by flipping a switch — you'll wonder how anyone builds alone without this.
The bookThe Solopreneur RevolutionLuis Gonçalves on building a solopreneur business with AI while employed.Get the book →Frequently asked questions
What is the difference between a feature flag and a setting?
A setting stores a preference — timezone, theme, currency. A feature flag stores a decision about availability: is this feature on, and for whom? They live in the same hierarchical system (global default → organization override → user override), which is why the flag machinery is usually built as part of your settings system.
What is the difference between a feature flag and a rollback?
A rollback reverts your whole deployment to the previous version — effective, but it takes the good changes down with the bad. A flag switches off one specific feature and leaves everything else running. You want both: rollbacks as the emergency brake, flags as the precision control you reach for first.
Do feature flags slow the app down?
Not if they're cached. The flag check runs constantly, so the answer must come from a cache that refreshes when a flag changes — never a fresh database query per page load. Done right, the cost is effectively zero.
Can a non-technical founder manage feature flags?
That's the entire point. Flags move launch decisions out of code and into a dashboard: you decide who sees what, and when, without touching a deployment. You direct the rollout — 10% today, everyone on Monday — the same way you'd schedule a newsletter.
How trapped are you, really?
Take the Corporate Suffocation Index, the free solopreneur readiness assessment.