I watched a team spend three weeks chasing a bug that let a paying customer see a premium dashboard for free. The code wasn’t broken. The flag was. Someone had turned on new-reports-v3 for a beta group back in March, then the account upgraded through Stripe, and nobody ever updated the flag. The customer got the feature for free for four months.
That’s the trap with flags. They start as a deployment tool, then quietly become your access control system, and one day you realize your pricing logic lives in a config file that nine people can edit. If you’ve ever shipped a feature toggle for a beta launch, you already know how this goes: the flag works perfectly until billing sneaks into the picture.
The clean way out is separating release control from access control. That’s a distinction worth understanding if you’re selling in tiers, especially since many teams lean on feature flag management tools long past the point where those tools actually fit. Here’s where flags genuinely shine, where they quietly fail, and what to build instead.
What flags are actually good at
Feature flags were born for shipping. You wrap a code path, deploy to production, and flip a switch when you’re ready. No redeploy, no 2 a.m. rollback. That alone justifies the tooling.
They’re brilliant at a few specific jobs:
- Rolling out a risky refactor to 1 percent of traffic before the full blast
- Killing a misbehaving endpoint in one click when your monitoring lights up
- Letting your sales team demo an unreleased feature to one prospect by hand
Notice what’s missing from that list. Nothing about “who paid for this.” Flags evaluate simple attributes like user ID, environment, or a percentage bucket. They’re not designed to know whether an invoice cleared.
If you’re running a small product with two plans and a handful of customers, flags are honestly fine. I’d tell you to keep using them. The calculus flips the moment your pricing gets interesting.
Where the access logic starts to leak
Pricing complexity is the real culprit. Once you’re selling seats, usage credits, add-ons, and a hybrid contract with a signed enterprise customer, your flags multiply. You build one for the trial experience, one for the pro tier, one for the usage ceiling. Six months later you’re staring at a flag dashboard with forty toggles and no clear owner for any of them.
When flag configs and billing systems drift apart, someone has to reconcile them by hand. A missed toggle means a free upgrade or a locked-out customer. Neither one is a fun support ticket.
If you take payments through a platform like Stripe, your billing state already lives in a subscription object with statuses like active, past due, and canceled. Flags don’t read that object. So you end up hand-coding the bridge between “subscription is active” and “show the reporting tab.” That bridge is where bugs crawl in.
The entitlement pattern, in plain terms
An entitlement is a simple idea: a record of what a specific customer is allowed to do, evaluated at the moment they make a request, based on plan, usage, credits, and contract terms. Instead of asking “is this flag on for this user?”, you ask “does this account have access to the advanced reporting feature right now?”
Here’s the shift that matters. Flags live in your deployment config. Entitlements live in your business layer, and they read from the same place your billing does. When a subscription changes, the entitlement changes. No manual reconciliation, no stale toggles.
I’ve come to think of it as the two-layer access model. Layer one is release control: flags that decide whether code runs, in what environment, for which internal cohort. Layer two is access control: entitlements that decide whether a customer gets what they’re paying for. The rule I’d commit to is simple. Flags answer “should this deploy?”, entitlements answer “did this account pay for it?” Keep them in separate buckets and neither one has to do the other’s job.
Building this from scratch isn’t trivial, but the architecture isn’t exotic either. Library documentation like Martin Fowler’s writing on feature toggles is a good starting point if you want to see how the concept got split apart in practice.
A practical walkthrough
If you’re ready to untangle the mess, start here. This is the sequence I’d follow in your shoes:
- Audit every flag. List each one and tag it as release, experiment, or access. The access ones are your problem.
- Define the entitlements. For each access flag, write down what a customer needs to have to see it: which plan, which usage threshold, which contract clause.
- Map to billing state. Connect each entitlement to a status your payment system already tracks, like active, trialing, or past due.
- Evaluate at request time. Have your app check the entitlement when the customer hits a feature, not at build time.
- Retire the old toggles. Turn off access flags only after the entitlement path is live and tested.
The order matters. Teams that start by ripping out flags end up with broken doors. Teams that start by adding the entitlement layer can run both systems side by side, then cut over safely.
One more thing worth doing: log every entitlement check. When a customer calls about a locked feature, you want to know why it was denied without paging three engineers.
Security posture you shouldn’t skip
Access control is an authentication-adjacent concern, and the government’s baseline for access enforcement is a reasonable reference point. The National Institute of Standards and Technology maintains guidance on identification and authorization that’s worth a read before you build a homemade entitlement check from scratch.
At a minimum, don’t let the client decide what it can access. Entitlements belong on the server. If your frontend fetches a plan name and renders the premium tab accordingly, you’re one dev-tools change away from giving everyone the premium experience.
The judgment call
Not every SaaS product needs an entitlement system. If you’ve got one plan and no usage limits, flags will serve you fine for a long time, and I wouldn’t push you toward complexity you don’t need yet.
The signal to switch is when your pricing runs on more than one dimension at once. The moment a customer can be on a plan, a trial, a credit pack, and an enterprise exception all in the same month, flags stop being a tool and start being a liability. That’s when engineering stops shipping and starts firefighting.
The teams I’ve seen do this well made one decision early: they stopped asking flags to know about money. They kept flags for releases and built a separate layer for access, and when pricing changed, nobody had to remember which toggle to flip. Your release process deserves that same peace of mind.
Take a hard look at your flag dashboard this week. Count how many toggles are really about billing. If the number surprises you, your access layer is telling you something. What would change if you could ship a pricing update without touching a single flag?
