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 the vendor's open-source upstream, owned by you, hosted by the vendor 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.
What it takes to be in the category
Two facts must hold. Each is checkable, not a marketing posture.
Constitutive requirement 1
Open source you can actually fork
Everything needed to run the service — frontend, backend, deploy tooling, and the built-in agent where there is one — is open source under a license that permits forking, modifying, and operating commercially. If any component your fork needs exists only on the vendor's side, the fork right is fiction and the service is not in the category.
Constitutive requirement 2
You can pay to be hosted and supported
The vendor sells a hosted, supported offering under which you hold no agreements of your own with DNS registrars, cloud compute, TLS, inference providers, or any other infrastructure party. Open source without a purchasable host is admirable — but it's open-source software, not a SaaS category.
Both facts carry the fork-exit right: take your fork, your configuration, and your data to your own infrastructure 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.
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.
Level 1
Fork-Ready
The two requirements above, honored in full, exit right included. The hosted offering may still run one shared codebase for everyone. Much of the honorable hosted-open-source wave already stands here.
- Both constitutive requirements hold — forkable open source, purchasable hosted operation.
- Fork-exit right documented and honored: raw data exportable at any time in documented formats; a documented, runnable re-derivation path exists for derived artifacts using customer-owned credentials.
Level 2
Fork-Hosted
The vendor runs your fork. Your production instance is built from your own code line — one you can change — not from a shared main with your settings applied.
- Your production instance is built from your own fork —
not shared
mainwith per-tenant configuration. - Fork provisioning is a productized operation (self-service or SLA-bound), not bespoke consulting.
- A defined path for your changes to reach production: a pull request to your fork's main, then a deploy.
- The hosting-refusal boundary is documented: divergence is unlimited on the fork; the vendor may decline to host a given divergence; the exit right is the backstop and can never be declined.
- Merge economics are documented: clean upstream merges included in hosting; conflict resolution caused by your own divergence is billable work you order.
Two honesty clauses, stated up front because a promise with hidden conditions is worse than no promise. Your right to diverge is unlimited, but whether the vendor hosts a given divergence is the vendor's commercial and safety decision — nobody can be obligated to run arbitrary code on their own infrastructure — and your exit right keeps that refusal honest. And your divergence, your cost: that's what keeps pricing fair for the customer who never diverged.
Level 3 — the flagship
Self-Developing
A development agent lives inside the product, scoped to your fork. You order changes in plain language; the agent delivers every change as a pull request you can preview before you merge.
- A resident agent is embedded in the product itself, scoped to your fork.
- Change orders are expressed in natural language, in-product.
- PR-to-main discipline: every agent-produced change is a pull request against your fork's main; the agent holds no write access to main and no production deploy rights; a human with merge authority merges.
- Every agent PR carries a preview deploy usable before merge.
- The agent is part of the open-source stack and survives exit — only credentials and sandbox change hands.
The pull-request discipline is not bureaucracy; it is what makes a self-developing service governable. Every change is reviewed, previewed, attributable, and reversible. An agent that edits your live system directly is a demo. An agent that ships you reviewable PRs with previews is an engineering department.
Full criteria, terms, and invariants: the domain model and ADR-004.
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.
It is not open-core or source-available
If the enterprise features, the agent, or the deploy path are proprietary — or the license forbids competing with the vendor — the fork is second-class and the exit is partial. Fair-source and BSL licensing solve real business problems, but they solve them by limiting the fork right, which is the opposite of this category. Not in the category at any level.
Hosted open source on a shared main is the base of the ladder, not the top
Cal.com, Supabase, Ghost, Plausible and the commercial open-source wave got the foundation right: open code, optional self-hosting, an honest escape hatch. Dries Buytaert described that model as "Open SaaS" back in 2011, and it remains the closest ancestor of the fork-exit right. Those services stand at Level 1 today — inside the category, credited as its groundwork. What they don't yet do is host your main branch. One codebase, one roadmap; customers request, they don't order. Levels 2 and 3 begin where the shared main ends.
It is not malleable software, though it shares the goal
Ink & Switch and Geoffrey Litt's malleable-software research — and the local-first essay before it — articulated the conviction this category is built on: people should be able to reshape their tools, and ownership of your working environment matters. Local-first pursued that through data ownership on your devices. Fork-native pursues it for hosted, production, multi-user services — where the thing to own is not a file but a running system — through code ownership with an operations vendor attached.
It is not agentic-workflow SaaS
The current wave of "agentic" products embeds agents that do business work — answer tickets, chase invoices. Valuable, and orthogonal. A fork-native service embeds an agent that does development work on the product itself. Autonomy in operations is not autonomy in evolution — and workflow agents count for nothing on this ladder.
It is closest to — and distinct from — cloneable and agent-native SaaS
Builder.io's "cloneable SaaS" and the agent-native movement describe finished products you fork and let agents evolve; the Applied AI Society essay "Forkable is the new sticky" sketched the hosted-fork commercial logic — the vendor keeps the infrastructure, your fork keeps you — and Avery Software is building per-customer branches with AI-driven change today. This is the neighborhood the category lives in, and credit belongs where it's due. What none of them pinned down is the full contract: the unconditional exit right backed by a whole open stack, the vendor hosting the fork as the product, and the agent bound by pull-request discipline with human merge authority — graded on a ladder anyone can be measured against.
Why this is a stable equilibrium
A fair question: if customers can leave at any time, why does the vendor survive?
Because the vendor's revenue was never the source code. It is operations — infrastructure, upgrades, security response, the unglamorous work nobody forks a repo to acquire — and stewardship of the upstream that every fork benefits from tracking. Customers who can leave whenever they want mostly don't; retention that survives an open exit door is retention the vendor 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, 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.
qmd-hub
A hybrid-search and documentation-indexing service for AI agents: point it at documentation sources, get back fast hybrid search over them, exposed to agents via MCP. Built as open source across the whole stack — frontend, backend, indexing worker, resident agent, deploy tooling — and targeting Level 3 (Self-Developing) from day one: vendor-hosted forks with a built-in agent that develops the service itself, every change a pull request against your fork, every pull request with a preview deployment.
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.