Past your first enterprise contracts, every B2B SaaS ends up with a second product: the code that decides what the first one does for each customer. It is spread across three systems that don’t talk — what was sold, what’s switched on, what’s running — and held together by glue code that breaks on every pricing change. Kaiten is that second product, built once, in the open. One model. One audit trail. One source of truth.
THE PROBLEM
A column on the accounts table. An enum of plan names. A cron job that reads the CRM at night. A webhook from the billing provider that sometimes arrives twice. Around the twentieth enterprise customer, this second product is bigger than most features of the first — nobody owns it, and everyone depends on it.
When a deal closes, an engineer translates the contract into it by hand. When a customer asks why a feature is missing, three people and a Slack thread reconstruct what they bought. Before writing a line of Kaiten, we went looking for it elsewhere: dozens of conversations with founders, VPs of Engineering, product managers and account managers. Every one of them had it.
It gets rebuilt from scratch every time, because the tools that should hold the truth each hold a third of it. None of them knows what the customer paid for — so the glue between them becomes the system of record by accident.
Sales / Revenue
CRM · billing
Plans, negotiated prices, discounts, renewal dates. The contract is signed in the CRM. Somebody still has to translate it into what the product does — usually by hand, usually through a ticket.
Product
A flag tool · custom code
The targeting rule says “Pro customers.” The flag tool doesn’t know who is on Pro right now. The flag tool and the billing system never share a primary key.
Engineering
Argo CD · Kubernetes · Terraform
The pipeline knows what runs where. It doesn’t know which customer is on which version, in which region, under which plan. Three questions, three tools.
THE COST OF THE GAP
Every reconciliation script you write is the company telling itself the same lie: that the systems will eventually agree. They never do. The drift compounds, and the bill arrives during the next on-call.
A COMPOSITE STORY
Acme Corp is fictional. The three browser tabs are not.
Support pages the on-call. Acme reports the new dashboard isn’t rendering. “It worked yesterday.”
The engineer opens the flag tool.new-dashboard is enabled for Acme. So far, so good.
Opens the billing system. Acme is on Pro, subscription active, payment current. The plan includes the new dashboard.
Opens the deployment dashboard. It still lists Acme’s instance on v4.7.2, and the release notes say the dashboard shipped in v4.7.0. Right version, apparently.
A senior engineer joins the call. They check the rollout again: 100% for Pro customers. Acme is on Pro.
Found it. Acme’s instance moved to the EU region last week. The EU deployment runs v4.6.9, and its rollout was paused on Friday for an unrelated bug. Nobody updated the flag’s targeting.
The flag was right. The entitlement was right. The infrastructure was wrong. And no single tool could tell them that.
Today, answering “why isn’t customer X seeing feature Y?” takes three tools and a call. It should take one query.
WHAT KAITEN IS
Every customer, every license, every flag and every deployment live in one model, linked by the same records. Kaiten doesn’t replace your billing engine or your CRM — it gives them one answer to agree on.
OpenFeature-compatible flags over OFREP, with CEL targeting rules that read the customer's license, recorded usage and deployment zone on the server. Percentage, A/B/n and date-ramped rollouts, a kill switch, and rules you can lint and rehearse before saving.
Four entitlement types: on/off features, numeric quotas, AI credits and configuration values. Each grant carries its own policy — a hard limit, a soft limit with an overage allowance, or unlimited. Past the allowance, a usage report is refused with a 409 and recorded.
Versioned components, immutable releases, deployment zones with an append-only record of what ran where, and instances deployed onto and migrated between zones. Argo CD or Flux still deploy; Kaiten records what ran, as your CI reports it, and your flag rules can read it.
Customer, instance, license, entitlements, zone, release, flag: one chain of records, each linked to the next. One read-only GraphQL query spans customers, instances, licenses, entitlements, releases and usage; the REST API, the CLI and the MCP server read the same records.
WHAT WE BELIEVE
01 / 07The contract
Kubernetes taught operations to declare a desired state and let a controller reconcile reality toward it. A B2B SaaS has a desired state too — what each customer bought, at what price, with what limits, running where. Today it lives in a PDF, and people do the reconciling.
Today: Customers, Instances, Licenses and Entitlements share one model, and the server enforces the limits they grant.
02 / 07The capability
A flag is a mechanism. The capability it serves is planned, tried on a few customers, released, sold as part of a tier, measured and eventually retired — and when the flag is cleaned up, its history usually goes with it.
On our roadmap: the Feature as a first-class object, with its own lifecycle, that remembers every flag that ever gated it.
03 / 07AI credits
Customers need a stable pool of credits they can budget. Vendors need to decide how each model draws from it, and change that rule the day their provider changes prices — a setting, not a release. And Kaiten stays the control plane: it never sees a prompt.
Today: AI credits are an entitlement, enforced like any quota. On our roadmap: per-model conversion rules.
04 / 07Sovereignty
Banks, defense, healthcare and the public sector won’t let a vendor’s control plane run in a cloud they don’t control. Today that means losing the deal or forking the product. It should mean the same catalog and the same contract, enforced inside their perimeter.
In private preview, by invitation: Kaiten Edge, which will serve flags and entitlements offline and bring signed usage back for billing.
05 / 07The customer
Your CRM knows what a customer said, not what they did: which features they use, how close they are to a quota, whether the module they paid for was ever opened. An account manager should learn it from the customer’s usage, before the customer says anything.
On our roadmap: alert rules that open a task in your CRM, and a 360 view built on the data Kaiten already holds.
06 / 07Agents
No agent should have to guess what a customer is allowed to do from a comment in the code. Commercial rules have to be declared, typed and machine-readable — for the agents that build software and for the ones that run it.
Today: an MCP server exposes every Core API operation as a tool. On our roadmap: typed entitlements generated by the CLI, and a Skill for every capability.
07 / 07Open source
Kaiten makes the glue redundant, not your tools: your billing engine keeps invoicing, your CRM keeps the relationship, your pipeline keeps deploying. And infrastructure that holds a company’s commercial truth has to be inspectable. Nobody should put their entitlement logic in a black box.
Today: Kaiten is open source under Apache 2.0 — the engine, the SDKs and the CLI.
These seven convictions come from our vision article, where each one is argued in full.
Read “Kaiten: what we believe, and where we’re going”KAITEN BY KAITEN
The model and the API you get are the ones our own operations run on — so every friction reaches us before it reaches you.
In your SaaSEach of your customers, and each of their deployments.
Customers
In oursEach Kaiten Cloud organization is a customer, with an instance, in our own Kaiten.
In your SaaSEvery version you ship, as a component and a release.
Releases
In oursEvery tagged Kaiten release declares its artifacts as components in our own Kaiten — or the release fails.
In your SaaSYour regions and clusters, as deployment zones.
Zones
In oursEach of our hosted environments is a deployment zone.
In your SaaSRollouts behind flags that read the contract.
Flags
In oursOur console’s feature gates are flags in our own Kaiten.
In your SaaSThe public API and SDKs.
API
In oursOur own Kaiten is configured through the same public API and Go SDK.
WHAT WE WON’T BUILD
Kaiten sits above the tools you already run and makes them agree. We hold that line as a rule: the day a roadmap item reads like one of these, the answer is no.
Your billing engine keeps invoicing. Kaiten holds what was sold and counts what was used.
Your CRM keeps the relationship. Kaiten links each customer to its record there.
Kaiten is the control plane, not the data plane. It counts the usage you report and never sees a prompt or a response.
Argo CD, Flux or your CI keep deploying. Kaiten records which release runs where, and for whom.
Your warehouse keeps the analysis. Kaiten emits a typed event for every change it records.
Those events are yours to act on. The automation belongs in your own services, or in the tools built for it.
WHO IT’S FOR
Kaiten is for teams that already shipped something and now operate it across many customers, regions and pricing tiers. Below that threshold, you don’t need us. Above it, the glue code starts costing more than the product it connects.
WHERE WE’RE GOING
We measure our road in horizons, not dates. Everything on this line is still ahead of us.
01 / 04Horizon 1
Your own identifiers on every object, types generated from your catalog, drop-in components for the pricing page, the customer portal and the paywall, billing and CRM connectors, and the AI credit layer. The bar: under four hours from the first API call to the first entitlement check in production.
02 / 04Horizon 2
Kaiten Edge for air-gapped customers, metering from the events you already emit, cohorts and cascading configuration, usage down to the end user, per-customer release notes — and the System Map: what runs where, for whom, and what a change would break, in customers and revenue.
03 / 04Horizon 3
Cloud marketplace listings from the same catalog, a workflow engine with native commercial actions, customer intelligence that graduates from rules to models, and a community registry of skills and templates — so each new vendor starts where the others finished.
04 / 04Beyond
Access, metering, billing, deployment and the agents that operate them, all derived from one declaration. And an open standard for entitlements, the way flags have OpenFeature — written in code before it is written in a spec.
Kaiten is open source under Apache 2.0, SDKs and CLI included. Run it on your own infrastructure, or ask for Kaiten Cloud: the same engine, operated by the team that writes it.