Kaiten: what we believe, and where we're going

The product nobody planned to build

Every software company that sells to businesses ends up with two products. The first is the one on the website. The second has no name, no product manager and no line in the budget, and it is the code that decides what the first one does for each customer.

It starts small. 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. A YAML file that says which customer runs which version, maintained by whoever deployed last. Around the twentieth enterprise customer the 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. When finance asks who is over quota, the honest answer is a query someone will write next week.

The four of us have each built this second product in the SaaS companies we come from. Before writing a line of Kaiten, we went looking for it elsewhere: dozens of discovery conversations with founders, VPs of Engineering, product managers and account managers of other startups. Every one of them had it. The names of the tables changed; the story did not. It was the least loved code in the company and the most critical, and it had been built from scratch every time, because the tools that should have held the truth each held a third of it: the CRM knew what was sold, the feature-flag service knew what was switched on, the deployment pipeline knew what was running. None of them knew what the customer had paid for, so the glue between them became the system of record by accident.

Kaiten is that second product, built once, in the open, as infrastructure. This article is about what we believe and where we intend to take it.

---

What we believe

The contract is the source of truth for infrastructure

Kubernetes changed operations with one idea: declare the desired state, let a controller reconcile reality toward it. We think the same idea is missing one level up. A B2B SaaS has a desired state too, and it is not a Helm chart. It is the commercial contract — what this customer bought, at what price, with what limits, running where. Today that desired state lives in a PDF, and reality is reconciled toward it by people.

Kaiten treats the contract as the declaration and the product as the thing to reconcile. Licenses, entitlements, flags, deployments and metering live in one model with shared primary keys — and prices and features will join them there: an Organization sells to Customers, a Customer has Instances, an Instance runs under a License, a License grants Entitlements. One query answers the three questions every vendor asks — what did they buy, what can they use, where is it running — because the three answers were never separated.

Concretely, the core is deliberately small. A vendor declares its Customers and the Instances that serve them — one per environment, region or dedicated deployment — each placed on a Deployment Zone and running a Release of the vendor's Components. It declares its Licenses, and each License grants typed Entitlements: a right (can export), a quota (10,000 API calls a month), a configuration (365 days of retention). Feature flags are evaluated through OpenFeature, with targeting rules that can read the caller's License and Entitlements. At runtime, the vendor's application asks Kaiten two questions — is this flag on for this customer, and is this customer allowed to do this, with how much left — and reports what was consumed. Kaiten enforces the limits, hard or with an agreed overage, records every change and every evaluation in an audit trail, and emits an event for each state change that billing, CRM and the vendor's own systems can consume. All of it is reachable through a REST and GraphQL API, a console, and an MCP server.

This is why we describe Kaiten as a business-to-infrastructure state controller rather than a billing tool, a flag tool or a deployment tool. Those categories exist and they are good at their jobs. What they lack is the shared declaration that lets them agree. When the declaration exists, most of the glue has nothing left to do.

A capability has a life, and it deserves an object

The feature-flag industry has done something valuable: it gave the flag a lifecycle — define, develop, release, clean up, archive. But a flag is a mechanism. The thing it serves, the capability, has a longer life: it is planned, tried on a few customers, released to everyone, sold as part of a tier, measured, and eventually retired. Today that story is scattered across a ticket tracker, a flag tool, a pricing page and someone's memory, and the day the flag is cleaned up the history goes with it.

We believe the capability itself should be the first-class object. In Kaiten, a Feature will move through its own lifecycle — planned, alpha, beta, general availability, deprecated, archived — and everything else will attach to it: the flag that rolls it out, the entitlement that sells it, the events that measure it. When the flag is removed at general availability, the Feature will remember that it was gated by that flag, between those dates, for those customers. From experiment to invoice, one object will carry the whole story. No flag tool can offer this, because no flag tool owns the commercial layer the capability grows into.

A Feature will be followed from the engineering side as well. Every Release that changes it will be recorded against it, so its history will read as a timeline: shipped behind a flag in 2.1, reworked in 2.3, flag removed in 2.4. Its page will show who uses it most — the top customers, by usage and by License — and the Components it touches, in both directions: the services that implement it, and the ones whose changes can break it. When a Release ships a change to a Component, Kaiten will know which Features move with it and which customers will notice.

The credit, not the token, is the unit of AI commerce

AI broke the tier. Costs vary per token, per model, per call, and a fixed monthly price no longer survives contact with an inference bill. Vendors face three bad options: pass tokens through and watch customers panic at unpredictable invoices, expose opaque credits and watch them churn at the first surprise, or freeze per-model quotas and watch them feel cheated by the rigidity.

We believe the credit is the right abstraction — on one condition: the vendor controls the conversion. Today, the customer sees a stable pool of credits per License — an entitlement like any other, a unit they can budget and a CFO can sign. Next, the vendor will configure how each model and each request type draws from that pool, per License, and change the rule the day their own provider changes prices. Margin management will become a setting, not a release. A new model will launch in minutes: declare it, write three conversion rules, done.

And the boundary is deliberate: Kaiten is the control plane, not the data plane. It never sees a prompt or a response. The application calls the model directly and sends Kaiten the token counts, the model and the metadata. That keeps us out of compliance-sensitive paths, and it makes the credit layer usable by every vendor, whatever gateway or observability stack they already run.

Sovereignty is a product feature, not a deployment option

The largest customers a SaaS can win are the ones that will not let its control plane run in a cloud they don't control. Banks, defense, healthcare, public sector — and, increasingly, any European company reading DORA and NIS2 seriously. Faced with that demand, a vendor either loses the deal or forks: customer-specific charts, customer-specific code, a second product for one account.

We believe the vendor's hardest constraint should become their moat. Kaiten Edge, in private preview, will be an autonomous agent deployed inside the customer's perimeter. It will serve flags and entitlements fully offline, with sub-millisecond local evaluation, in air-gapped mode or with intermittent sync. Every evaluation and consumption will be written to a hash-chained, signed log; the customer will export it, the vendor will re-import it, and Kaiten will verify the chain, reconcile the usage and trigger billing. What was sold will be enforced where it runs, even where nothing can phone home.

A customer is a whole, not a tenant id

The revenue team meets its customers through the CRM, and the CRM knows what they said. It does not know what they did: which features they use, how close they are to a quota, whether their AI consumption doubled last month, whether the module they paid for has ever been opened. That knowledge exists, scattered across the second product, and nobody serves it to the people who could act on it.

We believe the account manager should learn about a customer from the customer's own usage, before the customer says anything. Kaiten's 360 view will be built only on data it already owns — entitlement usage, instance health, flag activity, license history, AI credits — a view no other tool can assemble. On top of it, alert rules will turn signals into work: no activity for fourteen days, usage down forty percent week over week, quota saturated three months in a row, five seats added in thirty days. Each rule will create a task in the CRM, with the reason attached. The account manager will not open a new dashboard; the dashboard will open their morning. We will start with honest rules, not "prediction". When a year of signals has accumulated, the rules will become the training set, and the health score will follow.

Software will be operated by agents, and agents need typed truth

More and more software is written by agents, and every application an agent creates needs lifecycle management from its first day. No agent will code an entitlements system from scratch, and no agent should have to guess what a customer is allowed to do from a comment in the code.

We believe commercial rules must be declared, typed and machine-readable. Kaiten ships with an MCP server so that an agent can create a License, define what it grants, gate a flag and provision an Instance without a human touching the console. Its CLI will generate typed entitlements in Go, TypeScript or Python that mirror the catalog exactly — the OpenFeature workflow, extended to entitlements. And every capability we ship will come with an MCP Skill; skills will be part of our definition of done, not a documentation project. Our ambition is for Kaiten to become the lifecycle-management reflex of any agent building a SaaS, the way Stripe became the payment reflex of any developer.

Consolidation, not competition — and open source as the price of trust

Kaiten makes a fragmented stack redundant: the feature-flag tool, the entitlement service, the metering pipeline, the home-grown AI credit layer. It does not compete with billing engines, CRMs, LLM gateways, deployment runners or data warehouses. Stripe and Lago keep invoicing, HubSpot, Attio and Salesforce keep the relationship, ArgoCD keeps deploying, Databricks or Snowflake keeps analyzing. Kaiten sits above them and makes them agree. The enemy is not any of those tools; it is the glue between them.

We hold that boundary as a rule. The day a roadmap item reads "build a billing engine", "build a CRM", "build an LLM gateway with prompt logging" or "become a general-purpose automation tool", the answer is no. The unified model is the moat; stretching it toward mature categories would dilute the only thing that makes it valuable.

And infrastructure that holds a company's commercial truth has to be inspectable. Nobody should put their entitlement logic in a black box, and no control plane gets adopted through procurement — it gets adopted by engineers, from a repository. That is why Kaiten is open source — the core, our SDKs and our CLI, all under Apache 2.0 — and why we run on it ourselves: our tiers are Licenses in our own production instance, our quotas are Entitlements, our customers' environments are Instances. Every friction reaches us before it reaches you.

---

One customer, one year, five people

Beliefs are abstract. Here is what they will mean over a customer's first year, once the pieces on our roadmap have landed, seen from the five desks that today never share a screen.

In January, an account executive will close Acme: a Pro License with a base fee and two metered prices, an analytics addon, a pool of AI credits, and a soft limit with a two-day grace period because Acme asked for it. She will build the contract in Kaiten from the catalog, in the same words the product uses, and it will be enforceable the moment it is signed. For the proof of concept, she will create a voucher that unlocks a beta feature for ninety days. No ticket will reach engineering.

The same afternoon, a backend developer will run the CLI. The generated types will already contain AnalyticsModule and AICredits; the paywall in the product will be a React component wired to the catalog; the check before each inference will be one endpoint. He will map Acme's tenant id onto the Kaiten Customer with a single field and never write a reconciliation script. Because the analytics module is an entitlement rather than an enum, there will be nothing to deploy.

A platform engineer will create Acme's Instance on the European zone; the pipeline will deploy release 2.3 to it and report it to Kaiten. The instance will belong to a cohort, "eu-sovereign", that carries the EU default model and the compliance flags, so Acme will inherit the right configuration in one gesture.

A product manager will watch the beta feature from the Feature's own page: on for Acme through the voucher, tracked through the events Acme's instance already emits, adoption plotted next to the other beta customers, segmented by tier. In April she will promote the Feature to general availability; the flag will be cleaned up and the Feature will keep the record that it was ever behind one.

In June, an alert will fire: Acme has been above eighty-five percent of its AI credits for three months. A task will appear in HubSpot with the numbers attached. The account manager — who sees Acme and her other accounts, and only those — will call before Acme calls her. The upsell will be an addon that stacks on the License; the customer portal will show the new limits the same evening. In November, when the team plans to deprecate a component, the System Map will show that Acme is on its path, along with fourteen other instances and the revenue they represent, before anyone touches the code. And when the renewal comes, Acme will read release notes for the version actually deployed for them, not the marketing feed.

Five people, five perspectives, one object. Nothing will be translated, because nothing will need to be.

---

Where we are going

We measure our road in horizons, and each horizon has a single question.

The first question is whether Kaiten can be adopted in an afternoon. A control plane that takes a quarter to integrate is a tech demo. So the near term is about being integrable: every object will accept your own identifiers; the CLI will generate your types; three React components will put the pricing page, the customer portal and the paywall on Kaiten from day one; Stripe and Lago will receive the metering and generate the invoice; HubSpot and Attio will receive the signals and route the alerts; the AI credit layer will go live in full. The bar we hold ourselves to is time-to-first-value under four hours — from the first API call to the first entitlement check in production.

The second question is whether Kaiten becomes irreplaceable once adopted. That is the work no point solution can copy, because it needs the whole model: Kaiten Edge, so that a customer inside an air-gapped perimeter is served from the same catalog and the same contract as any other. The measurement half of the Feature lifecycle, so that a SaaS that already emits events gets metering without a single line of accounting code. The operational axis of cohorts and cascading configuration, between the contract and the code. Usage down to the end-user, so a vendor sees the power users worth a conversation and the seats worth expanding. A public changelog and per-customer release notes, generated from releases and deployments rather than maintained by hand. And the System Map — the state controller made visible: components, releases, zones, instances and customers on one canvas, what runs today and what is decided next, with the blast radius of any change expressed in customers and revenue.

The third question is whether the model creates network effects. A platform is a place where each participant makes the others better off. Marketplace deployment will let a vendor publish on AWS, Azure and GCP from the same catalog it uses for direct customers, with provisioning that creates the Customer, the License and the Instance the moment the marketplace order lands. A workflow engine will turn the events the system already emits into durable automation with native commercial actions — when Acme upgrades, issue the welcome voucher and post to the sales channel — composed by humans or by agents. Customer intelligence will graduate from rules to models trained on the audit trail. Data will flow to the warehouse the customer already has. And a community registry of skills and templates — plan structures by industry, AI pricing patterns by vertical, anonymized benchmarks — will mean the thousandth vendor on Kaiten starts where the first nine hundred ninety-nine finished.

Beyond that horizon we can name the destination without pretending to know the route. We want Kaiten to be the control plane every B2B SaaS runs on: the place where the contract is written once and everything downstream — access, metering, billing, deployment, the agent that operates all of it — follows from it. We want entitlements to have a standard the way flags have OpenFeature, and we intend to write it in code before we write it in a spec. We want serving a sovereign, air-gapped customer to be as simple for a vendor as serving a classic SaaS customer — same catalog, same contract, no fork. And we want the map of a company's product — what exists, what is decided, who depends on what — to be a living object that engineering, product and revenue read together, because it is generated from the same truth they all work in.

---

Open, and live

Since October 1, Kaiten is open source and the product is live: the core, our SDKs and our CLI, all under Apache 2.0. The MCP server and the SDKs ship continuously, and the Skills will follow, so that a developer — or an agent — can plug Kaiten in and use it immediately. Kaiten Cloud is how we make a living above it: managed operations for teams that would rather not run it, and dedicated environments, on Cloud Enterprise, for those who must.

Four of us founded the company at Station F after building this kind of infrastructure together for years. If you have ever owned the product nobody planned to build, the repository is open. Come and look at the model. It already knows the shape of your problem.

— Alexandre Bergère, co-founder & CEO, Kaiten