LaunchDarkly pricing explained: what you actually pay at different scales

LaunchDarkly doesn’t publish a simple price. They publish a floor. What you actually pay depends on two variables that are hard to predict and tend to grow together: seats and Monthly Active Users.

This post breaks down how those numbers compound and what teams typically find when they first look at the actual bill.

The two meters

LaunchDarkly’s paid tiers charge on two axes simultaneously:

Per seat — roughly $20/seat/month on the Foundation tier, higher on Pro and Enterprise. “Seat” means anyone with a dashboard login.

Per MAU — Monthly Active Users, metered by how many unique users evaluate flags in a given month. The base tier includes a floor (around 1,000 MAU), and you pay for overages above that.

Most teams hit the MAU meter long before they expect to. If you have a B2C product or a high-traffic API, your MAU count reflects your user base — not your team size.

What it costs at real team sizes

Let’s price out a few common scenarios. These are estimates based on publicly available LaunchDarkly pricing; actual contracts vary.

10 engineers, 50K MAU (Series A startup)

• Seats: 10 × $20 = $200/month
• MAU overage: ~50K × $0.015 = $750/month
• Estimated total: ~$950/month

25 engineers, 200K MAU (growth-stage)

• Seats: 25 × $20 = $500/month
• MAU overage: ~200K × $0.015 = $3,000/month
• Estimated total: ~$3,500/month

50 engineers, 500K MAU (scaling)

• Seats: 50 × $20 = $1,000/month
• MAU overage: ~500K × $0.015 = $7,500/month
• Estimated total: ~$8,500/month

The seat cost scales with your team. The MAU cost scales with your product’s success. Both tend to go up.

The renewal problem

Most LaunchDarkly customers on Enterprise are on annual contracts. You negotiate at your current scale, agree on a MAU tier, and then your product grows. Twelve months later, you’re in an overage situation and the renewal negotiation starts from a higher baseline.

This is what teams mean by “renewal shock.” The number you agreed to last year no longer reflects the number you’re actually running at, and the vendor knows your migration cost is high.

Why MAU-based pricing exists

It’s worth understanding the model before you dismiss it. LaunchDarkly and older platforms were built when flag evaluation happened server-side — a request to their API for every flag check. At that architecture, MAU was a real proxy for compute cost. They served traffic; they charged for it.

Modern SDKs work differently. The SDK downloads your ruleset once and evaluates flags locally, in your app’s memory. No API call at evaluation time. The vendor’s infrastructure isn’t involved. The MAU meter is measuring something that no longer reflects the vendor’s actual cost structure.

LaunchDarkly still uses this pricing model. You can draw your own conclusions about why.

What teams tend to underestimate

Dashboard seats get political. At $20/seat, teams start managing access carefully. The PM who wants to run a rollout, the designer who wants to see flag state, the support engineer who needs audit history — each is a budget conversation. This is the hidden cost: the mental overhead of gatekeeping access to a tool that works better when everyone can use it.

MAU is hard to predict. If you’re a B2C product, a successful marketing campaign can double your MAU in a month. Your flag bill follows. The team that should be celebrating ends up reconciling an invoice.

The overage notifications come late. By the time you get an overage alert, you’ve already used the MAU. You’re not controlling spend in real time — you’re negotiating after the fact.

The alternative model

Flaggy charges $99/month flat for the Team plan. Unlimited seats. No MAU metering. The price doesn’t change whether you have 10K MAU or 10M.

This is possible because Flaggy also evaluates flags client-side. We never see individual evaluations. Our infrastructure costs are driven by the number of flag rules we store and sync — not by your user count. So there’s nothing to meter.

The tradeoff: Flaggy is a focused flag management platform. It doesn’t bundle in session replay, analytics, or A/B testing infrastructure. If you need a single tool that does everything, that’s a different evaluation. If you need feature flags that work well and don’t surprise you on renewal, the scope is the right size.

Making the switch

Most teams migrating from LaunchDarkly follow the same steps:

1. Export flags as JSON from the LaunchDarkly dashboard
2. Restructure to the target platform’s format (usually 1-2 hours of scripting)
3. Run both SDKs in parallel during transition — old flags on LD, new flags on the new platform
4. Cut over fully once you’re confident

The SDK swap is the same pattern as any dependency replacement. The main cost is time, not complexity.

If you’re mid-contract on LaunchDarkly, the math is often worth doing: what does Flaggy cost for the rest of the contract term versus staying on the current plan? For most teams at the sizes above, the delta is meaningful.