Series A flags: fix the billing model before the meter bites

You hire two engineers. Proper hires. They need to ship behind flags like everyone else, which means they need console access, not a shared password and a Slack thread titled “please flip staging”.

So you go to add the seats.

And that is when you find out the “serious” flag vendor you picked at ten people was never really priced for the next two. Extra seats cost money. Or you bump a tier. Or you sit on the request until someone with a card says yes. Meanwhile the new people are already in the codebase writing if (flag) branches against an account they cannot open.

Then the month closes.

Traffic was up (good). Client-side evaluations were up (also good, if you are trying to find product-market fit). The usage meter noticed. The invoice that lands is not the one you mentally budgeted when the free tier or the startup deal still felt fine. It is seats plus growth. Two curves. One line item. A long sigh from whoever has to explain tools spend this month.

That pattern is the whole post.

I build RocketFlag in Perth, so yes, I have a horse in this race. I have also built enough half-arsed flag systems myself (env vars, a boolean in Redis, a “temporary” JSON file that somehow survived three quarters) to recognise when a team has outgrown the DIY path and walked straight into a meter without meaning to.

This is for the messy middle. Seed through early Series B. Not pre-product. Not enterprise procurement with a platform team and a change advisory board.

Why this stage is awkward

Pre-seed, you can live on env vars and a Redis key. Nobody cares. Nobody should.

Post-Series B, you might have a platform team, a compliance checklist, and a vendor relationship that is too expensive (and too woven in) to unwind on a whim.

Series A sits in between, and it is where the billing model becomes load-bearing for the release process. You need real flags: percentage rollouts, kill switches, per-environment config, maybe cohorts for beta customers. You don’t yet need a full experimentation platform glued to every release. You also don’t want infrastructure that charges you again every time hiring or traffic does what you raised money to do.

Flags feel like plumbing. They are plumbing. Plumbing that every engineer touches, that product asks about in standup, and that shows up as a surprise on the bill the month after you finally ship something people use.

The technical half first: seats are part of how you ship

Feature flags only work as a team practice if the people writing the code can see and change them.

That means seats. Owners, editors, maybe a contractor for a fortnight, maybe a founder who still merges PRs. Pricing that treats “add the two people you just hired” as an upsell is fighting how flags get used day to day. Shared logins are the workaround everyone pretends is fine until it is not. (Security theatre meets seat maths. Urgh.)

So the first bite is often not abstract “MAU philosophy”. It is concrete: two new GitHub handles, two people who need Staging and Prod toggles, and a vendor console that says not without paying more.

Then the usage half catches up

Metered flag pricing usually couples to people and usage.

People: seats, members, who can log into the console. Usage: MAUs, client-side contexts, API requests, how often your app asked for flags.

Hiring is the plan at Series A. Usage growth is the plan at Series A. The vendor that looked cheap at ten people and a quiet Tuesday becomes a recurring surprise when you are twenty-five people and the product is finally busy.

Concrete version, end of month:

You added those two seats (or delayed adding them and slowed the team down). Same month, you shipped the client-side SDK path that evaluates on every session for a multi-tenant app that just landed design partners. Evaluations climb with the thing you wanted: real users. The meter is doing its job. Your bill is doing theirs. Finance (or you, if you are still the CTO wearing that hat) asks why the “small tools” line moved.

I’m not claiming every competitor is out to get you. The incentives are just obvious. Their revenue tracks your growth. Your job is to notice that before the meter is woven through every service.

RocketFlag’s pitch is boring on purpose: one flat price. Unlimited seats. Unlimited evaluations. No MAU counting. Teams is about A$79 a month (about US$52). The bill doesn’t move when you hire, and it doesn’t move when your users show up. (Yes, that is the whole product story. I have repeated it so many times that my friends can recite it. Still true.)

Coursebox is the proof point I can name. High B2B2C evaluation volume on a flat Teams price. That’s the evaluations half in the wild. The seats half is simpler: invite the whole eng team, including the two people who started this month, without doing seat maths in a spreadsheet at 11pm.

What you actually need vs what you pay for

Most 5-30 person teams need flags that are fast and boring. Environments that match how you ship (dev, staging, prod, maybe a preview). Percentage rollouts and kill switches. A way to target a cohort without inventing a second system. An invoice you can explain in one sentence.

Most of those teams don’t need, yet, a multivariate experimentation suite inside the flag product. Or enterprise change-request workflows. Or a vendor that also wants to be your analytics company.

Cards on the table: RocketFlag is flags only. Percentage rollouts, cohorts, per-environment config. If your roadmap says “we need LaunchDarkly-shaped experimentation and governance from day one,” we’re not the right tool. I’d rather lose that deal in a blog post than waste your afternoon on a demo that ends in polite disappointment.

If you only need flags, paying for a platform you are not using is how Series A budgets get weird. Spot on tooling for a problem you do not have yet is still a cost.

“We will migrate later” (famous last words)

The comforting story is that you will switch after the next raise, or after the next hire, or after the next painful invoice.

Later is harder. More SDKs. More flag keys. More tribal knowledge about which dashboard is source of truth. More “do not touch that, it is load bearing.” Migrations are doable. They are never free. I have watched teams postpone the decision until the meter was the least fun part of every release.

I’m not telling you to rip out a working system this week for ideology. That would be a good way to break prod while explaining pricing philosophy. I’m telling you to run the forward-looking numbers once:

Seats in six months if hiring goes to plan (including the next two people, not just headcount today). Evaluation or MAU or request volume if usage goes to plan. What that implies on your current vendor’s public pricing (or your actual invoice). Whether you are paying for flags, or for a wider suite you hardly touch.

If that exercise says you are fine, great. Keep shipping. If it says the line item doubles while you are still trying to find product-market fit, you have a decision, not a vibes debate.

A simple Series A rule of thumb

Treat feature flag billing like any other infrastructure decision that scales with headcount and traffic. Prefer tools whose price stays mostly fixed while you are still figuring out the business. Pay for complexity when you have the process (and the budget) to use it.

We built RocketFlag for that ICP: smallish eng teams that want flags without a success tax. SaaS. Flat Teams price. Unlimited seats and evaluations. Compare: LaunchDarkly, Flagsmith. Pricing is here if you want the flat Teams number with no surprises.

We won’t win if you need the fancy extras. We should win if you want the release-control basics and an invoice that stays still while the company does not.

Dry honesty, because the cold email circuit trains it into you: if a vendor cannot tell you when they are the wrong fit, be suspicious. Here is ours. Flags only. No MAU meter. If that’s not enough product, pick someone bigger.

If you are seed to Series B, need flags, and the meter is starting to get to you (new hires blocked on seats, or last month’s bill made you sigh), that is why RocketFlag exists. If you are happy on what you have, don’t switch for a blog post. Ship the product instead.

Cheers, JK