Why Kaiten?

Every B2B SaaS eventually rebuilds the same thing: an internal system that connects what was sold to what the product does. It is rarely planned. It accretes — a script here, a webhook there, a database table nobody remembers creating. By the time it is load-bearing, it is fragile, undocumented, and owned by no one.

Kaiten replaces that system with infrastructure you do not have to build.

The problem: three systems that drift apart

When a B2B SaaS scales, three concerns end up living in three disconnected tools.

Sales owns what was sold. Custom pricing, discounts, and contracts live in a CRM and a billing tool. When a deal closes, someone — often an engineer — has to translate that contract into runtime reality.

Product owns what's accessible. Feature access runs through a feature-flag tool. But the flag only knows its targeting rule; it does not know what the customer paid for.

Engineering owns what's running. Instances span regions and clusters, with no knowledge of contracts or entitlements. The deployment runner knows what is running, but not for which customer or on which License.

None of these three share a primary key. So you write code to keep them aligned: a script that reads a closed deal and flips a flag, a webhook that updates an entitlement when an invoice is paid, a nightly job that reconciles who-has-what. This is the glue code, and it breaks.

What it costs

The fragmentation has a cost, and it shows up in the same places:

• Engineering capacity goes to maintaining the internal licensing-service — billing reconciliation, flag-to-entitlement sync, custom contract logic that serves no customer.
• Custom enterprise deals wait on engineering, because sales negotiates, engineering codes the entitlement, and ops verifies billing — every deal sits in an implementation queue.
• Selling on a cloud marketplace takes a paid listing tool or a homegrown integration.
• Revenue leaks through entitlement misconfigurations that nobody catches, because no single system has the full picture.

Why now

This problem has always existed. Three forces make it urgent today.

AI breaks billing. Costs are now variable per token, per model, per call. Fixed-tier pricing no longer holds, and the tools do not help: your billing system does not know which model a customer used, and your flag tool does not know what they paid for. The commercial layer between AI cost and customer pricing does not exist as standard infrastructure.

Agents build software. Every app an AI agent scaffolds needs lifecycle management from day one — and no agent is going to hand-write an entitlements system. They need a system to call. Kaiten is built to be that system: its whole model sits behind one API with a published OpenAPI specification. An MCP server that exposes that API as tools for AI assistants is on the roadmap Coming soon.

Compliance demands unified audit. SOC 2, DSP2, and the AI Act increasingly require answering "who had access to what, when?" in one query. Three disconnected systems cannot answer that; a unified model can.

The conviction

Kaiten rests on two beliefs. The first is the foundation; the second is its most urgent application.

First: the commercial contract should be the source of truth for infrastructure. The source of truth is the contract itself, modeled once and referenced everywhere, in place of the sales spreadsheet, the DevOps script, or a hardcoded enum buried in your codebase. Concretely: when a customer renegotiates, you change the License, and every flag, every quota, every invoice line follows. One edit, no deploy. Everything else in Kaiten builds on this unified model.

Second: for AI-native SaaS, the credit — not the token — is the right unit of commerce. Customers should see a stable, predictable unit they can budget for; the conversion to real model cost — per License, per model — stays your business to control, and the AI Control Plane Coming soon is where Kaiten makes it programmable.

What makes Kaiten different

There are excellent tools for pieces of this problem. None of them unify it — because none of them share a data model across the pieces.

Beyond feature flags

Feature-flag tools (LaunchDarkly, Unleash, Statsig) handle targeting well. But a flag tool does not know what a customer paid for, so you still wire it to your billing system by hand. Kaiten's flags read entitlements directly — gating a feature by License needs no glue. The flag rule references the entitlement.

Beyond entitlements

Entitlement tools (Stigg, Schematic) model plans and quotas well, but ship without a flag engine — so you bolt one on. Kaiten includes both, in one model. Typed entitlement definitions generated from your catalog, in your language, are on the roadmap Coming soon.

Beyond billing

Billing platforms (Stripe, Metronome, Orb) invoice well. They do not gate features or model deployments. Kaiten controls the rights and measures the usage; the billing engine generates the invoice. A provider-agnostic billing adapter, on the roadmap Coming soon, keeps you from being locked in.

The proof: the voucher

The clearest demonstration of the unified model is the voucher, on the roadmap Coming soon. A single Kaiten voucher will discount a price, boost an entitlement quota, and activate a feature flag — in one redemption.

Stripe coupons have no concept of a feature flag, LaunchDarkly has no commercial context, and Stigg has no flag engine. Kaiten's model allows it, because flags, entitlements, and commerce share the same primary keys.

What Kaiten makes redundant — and what it complements

Kaiten complements Stripe, your CRM, and your deployment runner: it integrates with them and makes them more valuable. What it makes redundant is the glue code between them.

What Kaiten builds on — and why it benefits you

Three things set Kaiten apart, and each reinforces the others:

1. The unified data model. Flags, entitlements, and commerce on shared primary keys; a flag rule that reads the License shows it today, and the voucher above is where it leads.
2. The AI Control Plane Coming soon. Credits as the commercial unit between your AI features and your LLM vendors, with conversion rules you control per License. The flag tools do not know what was paid; the billing tools do not know which model ran. Kaiten will know both.
3. Kaiten Edge Coming soon. The control plane that will work offline — serving flags and entitlements inside air-gapped environments with a tamper-evident audit trail.

Underneath all three: an open-source core, and agent-readiness — every capability behind one documented API.

For you, that means fewer tools to pay for and synchronize, native integration with the ones you keep, the ability to ship a billable feature in an afternoon, and access to customer segments — AI-native, regulated — that the fragmented approach cannot serve.

What if Kaiten-the-company goes away?

A fair question to ask any early-stage vendor.

The core is open source under the Apache License 2.0, and self-hostable. If we disappear tomorrow, your self-hosted stack keeps running, and the code is yours forever — to maintain, fork, or hire someone to extend. Your billing never left your billing provider's account. Your data is exportable. Nothing in your licensing layer depends on the company continuing to exist.

Compare that to building your entitlements into a proprietary cloud tool: if it shuts down, your licensing layer shuts down with it, and the migration is an emergency. With Kaiten, the worst case is that you maintain an open-source project. That asymmetry is why Kaiten is built open.

Next steps