Fork-Native SaaS

Your SaaS vendor's roadmap is not your roadmap

Software as a service won because nobody wants to run servers. It cost us two things we barely noticed giving away.

The first is the exit. Your data lives in someone else's database, your workflows in someone else's code. There is usually an export button; there is never a way to leave with the product. The price of not running servers turned out to be that leaving means starting over.

The second is quieter: the roadmap. When a thousand customers share one codebase, each customer's needs are averaged against everyone else's. You don't order changes to your tools — you request them, vote on them in a feedback portal, and wait. The feature that matters only to you is, by the economics of shared software, precisely the feature you will never get.

For decades this was a reasonable trade, because software was expensive to modify. Every custom change multiplied the vendor's maintenance burden, so vendors rationally refused customization and sold configuration instead.

That constraint just dissolved. AI agents can now implement, test, and document routine changes for roughly the cost of describing them. When modification becomes cheap, the shared-codebase compromise stops being an economic necessity and becomes what it always was structurally: a lock.

The fork is the natural contract between a software vendor and a customer in the age of AI agents.

Not a tenant account. Not a license. A fork: your own line of development, diverged from an open-source upstream, owned by you, hosted by a provider you choose for as long as that's convenient — and portable the day it isn't.

We call software built this way Fork-Native SaaS: the fork is a first-class citizen of the architecture and the business model, the way the cloud is first-class in cloud-native systems. At the top of the category, a fork-native service is self-developing: it ships with its own resident development agent, so the fork doesn't just give you the right to change your software — it gives you the means, without hiring anyone.

The option is the product

What does the customer actually get? Begin with the honest answer to the awkward question underneath it.

An option's value does not wait for its exercise. The fork-exit right pays out on the days you don't use it: every renewal, every support ticket, every pricing conversation happens with an open door in the room, and both sides know it. Running your own infrastructure will rarely be the economical choice — that is not a weakness of the right; it is why the right is shaped as an option. And when exit does happen, it is not divorce: most exits are a provider switch inside an open market — ordinary commerce, not escape.

You don't marry a vendor. Because the whole stack is open source, anyone may sell hosting, operations, and support for it — the upstream's own steward is simply the default provider, not the only one. Whoever can run the stack cheaper, closer, or better can open shop on an established market without asking permission. This is not a speculative mechanism: managed WordPress hosting — from global platforms to thousands of local agencies — has proven for two decades that a competitive provider market thrives on top of one open codebase. Fork-native SaaS generalizes that model to the whole stack and adds what WordPress never had: your own code line, and an agent to evolve it.

The contract gets freer with time, not tighter. An ordinary SaaS subscription deepens its lock as your data and workflows accumulate behind someone else's API. A fork-native contract moves the other way: one to three years in, there will likely be more providers competing to host you — and more forks to choose from, because forks that take their own direction can become new upstreams with new communities, exactly as open-source projects always have. Your switching options grow while you sleep.

Everything you order accumulates in something you own. In shared-codebase SaaS, the configuration, integrations, and custom workflows you build over years are rent — they vanish with the subscription. In a fork-native service every change order lands as code in your fork. You are not renting features; you are compounding an asset.

Your fork survives your vendor. When an ordinary SaaS shuts down, the product dies with it and you get ninety days to export what you can. A fork-native service cannot take your product down with it: the stack is open, your fork is yours, other providers exist, and stewardship of an upstream can be inherited. Vendor death becomes a provider switch you didn't plan.

Sovereignty stops being a compliance headache. An open provider market means you can choose a provider in your own jurisdiction — or switch to one the day a regulator, a customer, or a court requires it — with a data-processing agreement attached to a move you can actually execute. The EU Data Act now forces ordinary clouds to facilitate switching; a fork-native service exceeds that floor by architecture, not by compliance paperwork.

What it takes to be in the category

Two facts must hold. Each is checkable, not a marketing posture.

Both facts carry the fork-exit right: take your fork, your configuration, and your data to your own infrastructure — or to a competing provider — at any time, without permission or penalty. And we mean that precisely. Your raw data — sources, configuration, history — always leaves with you, as-is. Derived data — search indexes, embeddings — is often bound to a specific model and honestly cannot be promised as a portable byte copy; what the category guarantees instead is a documented, runnable re-derivation path on your own keys. A vendor that promises you exported vectors it knows you can't regenerate is selling exit theater.

And the right comes with a road. Every provider maintains an exit path: a documented, runnable procedure — data export in documented formats, fork transfer, re-derivation, cutover — on a defined timeline, at no fee. Exit is a product operation, not a negotiation. The economics are stated up front, in three honest layers: walking the path is free; being carried along it — hands-on migration labor you order from the provider — is billable work; and if you are migrating into a different, diverged fork at another provider, closing that divergence gap is your own cost. A right without a runnable path would be exit theater at the operational layer, and regulation already agrees: the EU Data Act forces switching mechanics on ordinary clouds — this category treats that as a floor to exceed.

The ladder

Membership is the floor, not the point. The category defines three conformance levels — in the spirit of the CNCF maturity ladder — and every criterion is a checkable fact. Each level includes all criteria of the levels below it.

One precision, because the provider market makes it matter: a level describes what you can buy, not what the code could do. A stack is Level 3-capable when everything needed for Level 3 exists in the open repository — a fact you can verify in the code. An offering conforms at Level 3 when that provider actually sells it, today. The same stack may be sold at different levels by different providers, and any provider may raise its offering to the stack's ceiling without asking anyone — that is one more axis the market competes on.

Full criteria, terms, and invariants: the domain model and ADR-004 through ADR-007.

Every service in the category should be climbing this ladder. The levels exist so that "fork-native" can be claimed honestly at the base and ambitiously at the top — and so you can tell, from checkable facts, which claim you're being sold.

What Fork-Native SaaS is not — and what it stands on

This category stands on prior work, and it's worth being precise about the differences — partly out of respect, partly because the differences are the definition.

Why this is a stable equilibrium

A fair question: if customers can leave at any time — and anyone may open a competing shop hosting the very same stack — why does anyone survive?

Because revenue in this category was never the source code. There are two honest ways to earn it, and they are the only two. The hosting provider earns operations: infrastructure, upgrades, security response, support, the data-processing agreements — the unglamorous work nobody forks a repo to acquire. The upstream steward earns stewardship: the position of default provider, closest to the upstream every fork benefits from tracking, best at the merges everyone needs. Neither is a moat; both are earned daily against an open market — which is precisely what makes the earning credible.

Customers who can leave whenever they want mostly don't; retention that survives an open exit door is retention the provider has earned. "Forkable is the new sticky" is not a paradox. Hostages compare escape plans; owners renew.

And the customer's side of the equilibrium is just as plain: you get vendor-grade operations without surrendering the roadmap, a market of providers competing for your fork instead of a landlord holding it, and — at Level 3 — an engineering department without headcount, one that ships you pull requests you can read, preview, and refuse.

The reference implementation

The definition above is product-neutral, and the top of the ladder needs an existence proof. Ours is on its way.

It is one product; the category is bigger than it, and the definition above is written so that the second, third, and hundredth fork-native service can climb the same ladder without asking anyone's permission — including ours.

That, too, is the point.