What is a SaaS Control Plane?

Somewhere between customer number 50 and customer number 200, every B2B SaaS discovers it has built something it never meant to build.

It's the system that knows which customers are on which plan, which features they have access to, how much API quota they've consumed this month, which version of the software is running in their cluster, and which Slack channel to post to when they upgrade. It exists, but nowhere. Parts of it live in Stripe, parts in LaunchDarkly, parts in a licensing-service repo, parts in an AWS Lambda triggered by a webhook nobody remembers configuring. The rest lives in a Notion document titled "How we handle enterprise customers" that hasn't been updated since last summer.

This system has a name. It's called a control plane. And whether you realize it or not, you're already building one.

This article is about what a SaaS control plane actually is, what it's made of, why most teams build theirs accidentally, and when it's time to treat it as a real product rather than a patchwork.

Where the term comes from

The phrase "control plane" is borrowed from networking and cloud infrastructure. In a router, engineers distinguish between the data plane — the part that actually forwards packets — and the control plane — the part that decides how packets should be forwarded. Kubernetes picked up the same distinction: the kubelet and container runtime form the data plane (they actually run your workloads), while the API server, scheduler, and controller manager form the control plane (they decide what should run where).

The pattern works because the two concerns evolve at different rates. The data plane is optimized for throughput and must be fast. The control plane is optimized for correctness and must be flexible — it's where the rules live, and the rules change more often than the traffic patterns.

The same distinction was carried into the SaaS world by AWS. In their SaaS Architecture Fundamentals whitepaper, they split a SaaS environment into a control plane — the services that "onboard, authenticate, manage, operate, and analyze a multi-tenant environment" — and an application plane, where the actual tenant-facing functionality lives. AWS makes one observation that's worth holding onto: the control plane is global to all tenants, not itself multi-tenant. It sits above the application, not inside it.

That framing maps cleanly to B2B SaaS, with one caveat. AWS's whitepaper is centered on the operational concerns of a cloud provider hosting a SaaS application — onboarding, authentication, tenant management. A modern B2B SaaS control plane has to cover more: entitlements, feature flags, deployment topology, voucher-driven monetization, and increasingly, agent operability. Same architectural pattern, larger surface area.

So a SaaS company has the same split, even if no one says it out loud.

• Your application plane (or data plane, depending on which lineage you prefer) is the application your customers actually use. The API calls. The UI. The database queries. The things they're paying for.
• Your control plane is everything that decides how that application should behave for each customer. Their plan. Their quotas. Their feature access. Their deployment topology. The notifications sent to your team when they upgrade.

Most B2B SaaS teams spend years treating the control plane as "glue code" around the real product. That works until it doesn't.

What a SaaS control plane actually does

A mature SaaS control plane coordinates five responsibilities. You already have all five, even if they're scattered across five systems.

1. It knows who the customer is

Every operation depends on a customer identity. The same email address might be a Free user, a Pro trial, or an Enterprise contact depending on context. The control plane holds the canonical view: who they are, what organization they belong to, which deployment they're using, and what identifiers map to them in your other systems (Stripe customer ID, HubSpot contact ID, GitHub org, etc.).

2. It knows what they paid for

Plans. Entitlements. Quotas. Add-ons. Custom negotiated terms. The control plane holds the contract as data, not as a PDF in a Google Drive folder. When your code asks "can this customer call this API?", the answer comes from here — not from a hardcoded if (plan === 'enterprise') buried in your handler.

3. It controls what code runs for them

Feature flags. Rollout percentages. Kill switches. Beta programs. Dark launches. These answer a different question than entitlements — not "did they pay for it?" but "is the code ready to run?" In a healthy control plane, flags and entitlements are aware of each other so that shipping a premium feature to 10% of Pro customers is one action, not two systems manually synchronized.

4. It tracks what's actually running

For multi-tenant SaaS, this is just "what version is in production?" For single-tenant or regulated deployments, it's a richer problem: which component is at which version in which customer's cluster, when was it last upgraded, is it in a Deployment Zone with specific compliance constraints. The control plane holds the ground truth — not the spreadsheet.

5. It reacts to what happens

Every interesting event in a SaaS — a license is assigned, a trial expires, a quota is exceeded, a feature is toggled, a deployment migrates — should trigger something downstream. A Slack notification to the AM. A voucher issuance. A CRM sync. An email to the customer. Historically this has been the "miscellaneous automations" folder: webhooks, cron jobs, Zapier flows, and ad-hoc Lambdas. A real control plane provides an orchestration layer so that these automations live alongside the data, not outside it.

Why most teams build theirs by accident

When you have 10 customers, you don't need a control plane. You hard-code the plan checks. You use LaunchDarkly for flags. You deploy manually. If Sales closes a special deal, the CTO edits the database. It works.

When you have 100 customers, the seams start to show. You adopt Stripe Metered Billing. You add a licensing-service. You write a webhook handler that listens to customer.subscription.updated and updates a Redis cache. You build a dashboard in Retool that shows who has what plan. You automate the onboarding email with a HubSpot workflow. None of it is a control plane, but the intent is there — you're trying to make the commercial contract drive the product behavior.

When you have 500 customers, the patchwork breaks. Here's what you hear in engineering Slack channels at this stage:

"Can we give Acme +500 API calls for 3 months? They're upgrading soon." "Why did we bill them $180K when the contract says $150K?" "The new dashboard is supposed to be Pro-only but the Free users can see it." "The deployment script pushed v2.4.0 to the EU cluster but our records still say v2.3.8." "Why didn't the welcome email go out when we activated Enterprise for Finch Inc?"

Each of these is a symptom of the same structural issue: the control plane is distributed across too many systems that don't know about each other. Stripe doesn't know what's deployed. LaunchDarkly doesn't know what the customer paid. The onboarding workflow doesn't know whether the customer is on a custom plan. The audit trail, if it exists, lives in CloudWatch logs nobody can search.

At this stage, most teams do one of three things:

1. Ignore it and bleed velocity quarter after quarter
2. Build it — dedicate a team to a "platform" project that takes 2 years and is never really finished
3. Buy it — adopt a control plane product or framework

Historically, option 3 wasn't really available, because no one had packaged the pattern as a product. That's changing.

The anatomy of a good control plane

Whether you build one or buy one, a good control plane has six properties. These aren't features — they're structural design choices that determine whether the control plane will scale with you or become the next thing that needs replacing.

A unified data model

Every entity — Organization, Customer, Instance, License, Entitlement, Feature Flag, Release, Deployment Zone, Cohort, Workflow — belongs to one coherent ontology. You don't have a "customer" in Stripe, a "user" in your database, a "subscriber" in your billing logic, and a "tenant" in your deployment pipeline. You have one Customer, one canonical schema, with ID mappings that bridge external systems.

The unified model is where the leverage comes from. A feature flag that can reference an entitlement. A cohort that can drive both a configuration value and a flag targeting rule. A workflow that can read a customer and create a voucher and notify a Slack channel. These are possible only if the underlying entities share a data model.

An event mesh

Every state change in the control plane emits an event. License assigned. Entitlement threshold reached. Deployment zone added. Customer metadata updated. These events are the public interface for downstream systems and automation.

The critical design choice: events are not just webhooks. They flow through a durable event mesh (RabbitMQ, NATS, Kafka, or similar) with replay, ordering guarantees, and at-least-once delivery. This means downstream automations can be added, modified, or replayed without touching the emitting code.

A shared audit trail — and the metrics that fall out of it

Every flag evaluation, entitlement check, license change, and workflow step writes to the same place. That single trail does double duty: it's the compliance record, and it's the usage dataset.

The compliance side is straightforward. When an auditor asks "prove customer Acme was entitled to SSO on April 15th at 14:00", the answer is one query away. When support asks "why did this customer's API call fail yesterday?", the trail shows the entitlement was at 101% of its monthly quota.

The metrics side is the part most teams underestimate. Because every entitlement check and every flag evaluation is recorded by the same system that knows the customer, the license, and the quota, you get usage and adoption metrics for free — no separate instrumentation, no mixpanel.track() sprinkled across the codebase, no reconciliation between Mixpanel and Stripe. "How many Pro customers use feature X this month?", "Which entitlements are over 80% consumed across our top 50 accounts?", "Has this customer's usage trended down in the last 30 days?" — these queries hit the same dataset that powers compliance. The audit trail and the metrics layer are not two systems. They're the same system, looked at from two angles.

A consistent expression language

The control plane uses one language to express rules, conditions, and targeting. Not three. Not a custom DSL for each subsystem.

In practice this means: the same syntax that targets a feature flag (instance.license.name == "pro") also defines a cohort membership rule (customer.metadata.region == "eu"), a workflow trigger filter (event.type == "LICENSE_ASSIGNMENT"), and an entitlement computation (usage.sum >= limit * 0.8). Your team learns it once and uses it everywhere. CEL (Common Expression Language), which Google designed for exactly this purpose, is the mature choice.

Open standards at the interfaces

The most defensible control planes bet on open standards at their integration points.

For feature flags, that means OpenFeature and OFREP. For agent operability, Model Context Protocol (MCP). For billing, a provider-agnostic adapter pattern that supports Stripe, Lago, Chargebee interchangeably.

Open standards at the interfaces mean two things. First, your customers can adopt your control plane without fearing vendor lock-in — they can always swap the backend if needed. Second, your own team inherits the ecosystem — SDKs already exist in every language, documentation is already written, and future tools integrate naturally.

Agent-operability from day one

This is the axis most control planes built before 2024 missed. Every capability in the control plane should be exposed via an agent-operable interface — typically MCP. An agent with context should be able to read the state, take actions, compose workflows, and orchestrate multi-step operations on behalf of a human operator.

This isn't a checkbox for an AI strategy. It's a structural shift in how B2B operations get done. The AMs who today file engineering tickets for every automation will, within 18 months, describe what they want to an agent and have it composed against the control plane directly.

Build, buy, or adopt

If you've read this far, you're probably recognizing pieces of your own stack in the description. The next question is what to do about it.

Historically, teams had two options. Today they have three.

Build it yourself. This is the path most B2B SaaS take by default — not as a deliberate decision, but because no coherent alternative existed. A platform team of three to five engineers spends 12 to 18 months stitching together a licensing-service, a webhook handler that listens to Stripe events, a feature flag tool with custom abstractions on top, a custom dashboard in Retool, a few Lambdas for automation, and an internal admin app for the AMs. It works. It also keeps requiring engineering investment forever, because every new commercial scenario — a custom enterprise deal, a new add-on, a regional pricing change — comes back as a ticket. Build makes sense if your control plane requirements are genuinely unusual and you're prepared to maintain it as a product line indefinitely. In practice, very few teams meet both conditions.

Buy point solutions and integrate them. This is the path of least resistance: LaunchDarkly for flags, Stigg or Schematic for entitlements, Stripe for billing, HubSpot for CRM, ArgoCD for deployments, Temporal for workflows. Each tool is good at what it does. The problem is that no tool owns the model — they each own a pillar, and the integrations between them become your engineering work. You haven't avoided the licensing-service; you've just renamed it "the integration layer." For most teams this is the worst of both worlds: vendor cost on the line items, plus engineering cost on the glue.

Adopt a control plane as a coherent layer. This is the new option. Instead of buying five tools and writing the integration, you adopt one platform that holds the unified data model — flags, entitlements, deployment topology, voucher-driven monetization — and complements the systems you already have for billing and CRM. The point is not to replace Stripe or HubSpot. The point is to stop writing the layer that sits between them.

This third option was unavailable for years because no one had packaged the pattern as a product. That's changed. Open-source control planes are emerging — Kaiten is one of them, MIT-licensed, OpenFeature-native, with a unified data model spanning the five responsibilities described above. But the category is bigger than any single project. The important thing is that the pattern now has a name, and teams who recognize it in their own stack will make better architectural decisions than teams who don't.

A short self-check

Three questions to ask your engineering organization this week:

1. If a new enterprise customer signs tomorrow, how many systems does someone have to touch manually to get them into production? Zero is the target. Most teams answer three to seven.

2. When a feature is rolled out to 10% of Pro customers, who updates the flag, who updates the entitlement, and do they talk to each other? "Same system" is the target. Most teams answer "different systems, manually synchronized."

3. When compliance asks what a customer had access to on a specific day six months ago, how long does it take to answer? Under an hour is the target. Most teams answer "days, if at all."

If any of these answers surprised you — or if you recognized yourself in the Slack quotes earlier in this article — your control plane is distributed across too many systems that don't know about each other. The good news: recognizing the pattern is the hard part. Fixing it is mostly a matter of committing to the pattern once and building (or adopting) the coherent layer, rather than adding more glue code.

The short version

• A SaaS control plane is the layer that decides how your application behaves for each customer — their identity, their contract, their code, their runtime state, and the automations that react to events.
• You already have one. It's just currently distributed across Stripe, LaunchDarkly, your custom licensing service, a dozen webhook handlers, and a Notion doc nobody reads.
• The pain scales non-linearly with customer count. What works at 10 customers breaks at 100 and becomes a full-time job at 1,000.
• A good control plane has six properties: unified data model, event mesh, shared audit trail (which is also where your usage metrics live), consistent expression language, open standards at the interfaces, and agent-operability.
• The choice is build, buy point solutions, or adopt a coherent control plane. The third option is new — and it's the one that lets you stop writing the integration layer.

Kaiten is the open-source SaaS control plane — a unified data model for feature flags, entitlements, and deployments, sitting on top of (never replacing) Stripe, Lago, HubSpot, or your CRM. Try the early access or star us on GitHub.