Why we chose flat pricing — and why it matters for your team
MAU-based pricing made sense when feature flags lived on the server. They don't anymore. Here's why we went flat and what it means for you.
Feature flag pricing has a dirty secret: most platforms charge you based on how many users evaluate your flags. That sounds reasonable until you realize evaluations happen in your users’ browsers, on their devices — completely outside the vendor’s infrastructure.
The MAU problem
Monthly Active Users. It’s a proxy metric for value that made sense in the early days of server-side evaluation. If every flag evaluation required a round-trip to the vendor’s API, charging per evaluation had some logic behind it.
But modern SDKs work differently. The SDK downloads your flag rules once (or keeps them fresh via streaming) and evaluates them locally. When a user hits a flag, nothing touches the vendor’s servers. The vendor pays no compute cost. Yet the meter keeps running.
What this means in practice
Consider a startup that ships a viral feature. Their DAU doubles overnight. Their flag bill doubles with it — despite the flag vendor doing exactly zero additional work. The team that should be celebrating is instead fielding an invoice question from finance.
This is the renewal-shock problem. You negotiate a contract at your current scale, ship something that works, and get punished for the success of it.
How Flaggy is different
Flaggy evaluates flags in your SDK. We don’t charge per evaluation because we don’t see evaluations. Your flag rules live in your SDK’s memory. The flag check is a local dictionary lookup.
Our costs are driven by the number of projects we host, the rules we store, and the API calls for dashboard interactions — not by how many users trip a flag condition.
So we charge a flat rate. One number. The same on day one as on day one thousand users. The same whether you’re doing ten thousand flag evaluations per hour or ten million.
The seat problem, too
Per-MAU isn’t the only pricing trap. Per-seat pricing means you’re constantly optimizing for who deserves dashboard access. A PM wants to manage a rollout? That’s a seat. A designer wants to check a flag’s status? Seat. A support engineer wants to look up audit history? Seat.
The mental overhead of managing seat access is real, and it subtly discourages the broad flag adoption that makes feature flags valuable in the first place.
On Flaggy’s Team plan, seats are unlimited. Invite everyone who touches your product. The price doesn’t change.
The tradeoff
Flat pricing only works if your costs are predictable. Ours are, because we don’t process individual evaluations. If we did, flat pricing would be a bet we’d eventually lose.
The architectural constraint and the pricing model are the same decision.