LaunchDarkly Killed Per-Seat Pricing. Meet the New Tax.

For years, the standard complaint about LaunchDarkly was per-seat pricing. Teams literally shared logins to keep the bill down. There are Reddit threads about public companies writing hacks to rotate seats between engineers. Everyone hated it, LaunchDarkly heard it, and in 2026 they did something about it: seats are now unlimited, on every plan, including the free one.

Credit where it’s due. That’s a real improvement, and if you’ve been holding your nose at seat-sharing hacks, it’s gone.

But the money didn’t disappear. It moved. And I’d argue it moved somewhere worse.

The new meters

LaunchDarkly’s paid Foundation plan now bills on two lines (annual rates; monthly billing runs about 20% higher):

• $10 per service connection, per month. Roughly: each service of yours that talks to LaunchDarkly.
• $8.33 per 1,000 client-side monthly active users, per month.

The free Developer plan is genuinely decent, with unlimited seats and flags, but it caps at 5 service connections and 1,000 client-side MAU. If you’re building anything consumer-facing, you’ll blow through 1,000 MAU the week your Show HN post gets traction. The free tier isn’t a small-team tier; it’s a trial with a growth trigger built in.

Do the calculations on a growing product

Say you’re a small team with a web app. Six services, client-side flags in the browser, 10,000 monthly active users. Your Foundation bill:

• 6 connections × $10 = $60
• 10 × $8.33 = ~$83
• ~$143/month. Fine. Reasonable, even.

Now the good scenario happens: eighteen months later you’re at 200,000 MAU. Same team. Same six services. Same flags, doing the same job: gating releases, running the odd canary.

• 6 connections × $10 = $60
• 200 × $8.33 = ~$1,666
• ~$1,726/month. Over $20,000 a year.

Your bill went up 12× and nothing about your use of feature flags changed. Not the number of flags, not the number of engineers, not the complexity of your rollouts. The only thing that changed is that more people visited your product.

That’s the part worth staring at. And note which meter did the damage: connections were flat the whole time. The growth in your bill is almost entirely the MAU line, the one that tracks your users, not your usage.

Why per-MAU is the wrong meter for flags

I get why usage-based pricing exists. For some products the meter tracks value: more Datadog hosts means more infrastructure being monitored, more Postmark emails means more mail actually sent.

Feature flags aren’t like that. The value of a flag system scales with the complexity of what you ship: how many features are in flight, how carefully you need to roll them out, how fast you need a kill switch. It does not scale with how many browsers evaluate the flag. A landing page with one flag and 500k anonymous visitors gets a huge bill for almost no value delivered. A gnarly B2B app with 40 flags, staged rollouts, and 2,000 logged-in users gets a small one. The meter is pointing at the wrong thing.

One more gotcha: “client-side MAU” means every unique browser context that evaluates a flag, including logged-out visitors. If you’re flagging anything pre-login (pricing page experiments, signup flows), your MAU count is your traffic, not your user base.

This is what I mean when I call it a success tax. Per-seat at least taxed something you controlled. Per-MAU taxes the thing you’re actively trying to grow. Your best month is your worst invoice.

To be fair to LaunchDarkly

If you’re running a serious experimentation program (A/B tests with stats engines, mobile release orchestration, the observability bundle), LaunchDarkly is a genuinely deep platform, and for a company at enterprise scale, $20k/year is a rounding error. The per-connection charge is also a defensible way to bill: it roughly tracks architectural footprint, and it stays flat as you grow. If they’d stopped there, this post wouldn’t exist.

The problem is specifically for small-to-mid teams that want flags (boring, reliable release gating) and are being billed as if they wanted an experimentation platform priced on traffic.

The alternative model

Obvious disclosure: I build RocketFlag, so I’m biased, and this is my pitch.

We charge flat. Free for solo devs. A$79/month for teams: unlimited seats, no MAU meter, no per-connection meter. A$999/month if you need audit logs and an SLA. In the scenario above, your bill at 10k MAU is A$79, and your bill at 200k MAU is A$79. The pricing page doesn’t need a calculator.

The trade-off is real and I’ll state it plainly: we’re flags, not a stats platform. There’s no built-in experimentation suite or session replay, and I don’t plan to bolt them on. Dedicated analytics and experimentation tools do those jobs better than a flag vendor’s side-hustle ever will. RocketFlag’s whole job is the flags themselves: evaluations served in milliseconds from regions close to your users, an API you can rely on during your worst deploy, and a price that stays put while you grow. If that’s what you need, that’s the entire product.

Run your own numbers before your next renewal. It takes five minutes, and the delta pays for a lot of things that aren’t flag evaluations.

Figures checked against LaunchDarkly’s public pricing page and GrowthBook’s analysis, July 2026. If they’ve changed since, run the numbers with whatever’s current; the shape of the argument doesn’t move.