From SaaS to SaaC: Why the Delivery Model Has to Change
SaaS was the right answer for twenty years. The question has changed — the caller is no longer human, and the unit of sale is no longer the seat.
Watch the episodeSaaS to SaaC Model | AIM Pattern | The AI Era ShiftThe Software Lens on YouTube →"SaaS was the right answer for twenty years. The question has changed."
What SaaS solved
To understand why SaaS is not the right delivery model for the next decade, we have to be fair about what it solved for the last two.
SaaS — Software as a Service — replaced on-premise installation with a multi-tenant hosted model. It solved, in one stroke, three enormous problems: distribution (anyone with a browser and a credit card could adopt), operations (the vendor ran the infrastructure, not the customer), and iteration speed (new features deployed centrally, not by an IT department upgrading a binary). The business model that rode these three solutions — per-seat pricing, annual contracts, net-retention metrics — produced the most efficient software companies in history. Salesforce, Workday, Atlassian, ServiceNow, Snowflake: SaaS was not just a delivery model; it was a business model that matched its delivery.
It is worth pausing on that last sentence, because the pattern-literate reader will recognize it as the decisive observation. Delivery models that match their business models compound; delivery models that fight their business models stall. SaaS compounded because the unit of sale (a seat) and the unit of delivery (a browser session) were the same thing, photographed from two angles. A CFO paid for seats; a user occupied a seat; the vendor measured seat usage; renewal negotiations turned on seat expansion. This tight loop — one unit, three stakeholders, zero translation loss — is what made the SaaS business model legible to finance, to engineering, and to customers simultaneously. Previous generations of software had no such unity: a shrink-wrapped licence, a perpetual-with-maintenance contract, and a user install were three different things that accountants reconciled by hand.
SaaS assumed, correctly for its era, that the caller was a human being at a browser. Every product decision flowed from this assumption. The UI was the product. The API was an afterthought, a B2B integration surface. Documentation was for developers doing one-time integrations, not for runtime discovery. Pricing was per-seat because humans sat in seats. Success metrics — DAU, feature adoption, session length — measured human consumption.
The assumption was so deeply embedded that most product teams never had to surface it. Onboarding flows assumed a human who could read. Notification cadences assumed a human who would be annoyed by too many pings. Rate limits were generous because a human could not realistically issue more than a few calls per second. Error messages were written in English prose because the recipient was a person. The entire vocabulary of "user experience" — friction, delight, flow, engagement — presupposed a biological nervous system at the other end of the wire. None of this was wrong. It was simply fitted to its caller, the way a saddle is fitted to a horse.
What breaks when the caller is an agent
When the primary caller becomes an agent — composed, stateful, negotiating multiple tools at runtime — every SaaS assumption breaks or bends uncomfortably.
The UI is no longer the product. The agent does not use the UI. The API becomes the product, and the API has to be shaped for reasoning callers (The Vocabulary of the Agentic Era's MCP, The Anatomy of a Capability and the Protocol Shift's capability manifest).
Per-seat pricing is wrong. An agent consumes a capability fifty times in a minute at 3 a.m. on a Saturday; it does not sit in a seat. Seat-based billing mis-prices usage in both directions — over-charging low-agent-use customers, under-charging high-agent-use ones.
Success metrics change. DAU is irrelevant; capability invocations per business outcome is the right metric. Session length is irrelevant; cost-to-resolution is the right metric.
Documentation becomes executable. A PDF of API docs is useless to an agent; an MCP manifest with semantic descriptions and example invocations is the minimum.
Integration becomes continuous. The model was: integrate once, operate for three years. The new model: agents discover capabilities continuously, compose them at runtime, and respond to new capabilities within hours of their publication.
Failure modes change shape. A SaaS outage is binary and loud — the login page errors, tickets spike, the vendor posts an incident. An agentic capability fails in subtler registers: a model's confidence collapses, an output schema drifts, a guardrail silently rejects a call. The operational discipline of SaaS — uptime dashboards, seat-based SLA credits, quarterly business reviews — maps poorly onto these subtler failures. New instrumentation is required, and that instrumentation lives at the capability level, not the tenant level.
Onboarding and offboarding cadence compress. A SaaS vendor sells to a buyer, provisions a tenant, sends a welcome email, schedules a kickoff. An agentic caller arrives, reads the manifest, negotiates scope, issues its first call, and either returns tomorrow or does not. The entire customer lifecycle shrinks from quarters to minutes. Sales-led motions do not disappear — large enterprise commitments still require human selling — but the default onboarding is self-service at machine speed, and products that are not shaped for this cadence leak adoption.
None of these are small changes. Together they amount to a different delivery model. I call it SaaC — Software as a Capability.
What SaaC is
SaaC is a delivery model in which the unit sold is a capability (The Vocabulary of the Agentic Era, deepened in The Anatomy of a Capability and the Protocol Shift): a manifest-described, MCP-surfaced, guardrail-bounded, outcome-measurable unit of organizational competence, priced by invocation and outcome.
The SaaC contract is not "we will let your users log in to our UI"; the SaaC contract is "we will make this capability available to your agents; it will respond within this SLA; it will respect these scopes; it will cost this much per invocation."
The shape is new. The precedents in software history are limited. Cloud infrastructure billing (per-API-call, per-GB, per-CPU-minute) is the closest analogue — AWS, Azure, and GCP pioneered pay-per-use at fine granularity twenty years ago, and SaaC is, in one sense, the same logic applied up the stack to organizational capability.
Side-by-side, the differences compound across every layer of the product and company. Billing moves from seats to calls; a seat-month is a proxy for value only if humans are the consumers, whereas a call is a direct measurement of work done on behalf of whoever asked. Onboarding moves from signup-and-provision to manifest-install; a tenant no longer needs to be stood up in advance, because the manifest is the tenant contract, negotiated at connection time. Integration moves from webhooks and CSV exports to MCP sessions; instead of configuring a callback URL and polling for changes, an agent opens a session, discovers the tools, and invokes them with session-level context. Failure modes move from outage dashboards to confidence collapse and groundedness drift; the SRE discipline survives, but its instruments change. Support moves from ticketed human help to machine-readable error envelopes and self-describing retry semantics. Pricing transparency moves from quote-and-negotiate to a public rate card an agent can simulate against before spending a dollar.
It is tempting to read this list as "SaaS with a different price meter," but that misses the structural point. SaaS and SaaC differ in the direction of the contract. A SaaS contract says: we let your humans in through this door, on these terms, for this fee. A SaaC contract says: we let your agents compose this capability into their own reasoning, on these terms, for this fee. The first invites people; the second licenses organizational competence. That shift — from a venue to a capability — is what every subsequent chapter in this stretch of the series elaborates.
the diagram renders the ten-row cheatsheet teams actually pin to the wall during the transition. Read the left column and every row is a human caller; read the right column and every row is a reasoning caller. The difference is not a repricing — it is a rebinding of every assumption the product was shaped around.
the diagram summarises the rebinding in a single glance: the publisher becomes the staffing agency, the capability becomes a specialist, the manifest becomes a résumé, the OLA becomes a performance guarantee, the registry entry becomes a directory listing, and the signed receipt becomes a payslip. Every business term on the right has a crisp equivalent on the left; no term on the right has to be invented from scratch. That is the value of keeping the HR metaphor load-bearing rather than decorative.
The Nexcubator business-model change
Nexcubator was sketched in Nexcubator as a single-window agentic platform for SMBs. The natural SaaS move would be per-seat pricing: $99 per employee per month. From SaaS to SaaC: Why the Delivery Model Has to Change argues this is the wrong move.
Instead, Nexcubator prices by capability:
hrm.retain— $0.18 per invocation, with a monthly-minimum commit.crm.next_action— $0.12 per invocation.pm.plan— $1.20 per plan generated.finance.collect— $0.40 per collection cycle executed.kb.summarize— $0.05 per summary.
Each capability has an SLA, a cost ceiling, and a published manifest. Customers can enable capabilities individually. Customers' own agents — not only Nexcubator's UI — can invoke the capabilities. Third-party platforms that integrate Nexcubator do so via MCP against the manifests.
This changes the commercial shape. Nexcubator is no longer competing with Salesforce-or-Workday on seats; Nexcubator is competing on the capabilities that matter most and letting customers compose it with anything else they have, including their own bespoke agents. The competitive moat is not the seat; it is the quality of the capability — its SLA, its accuracy, its guardrails, its compounding brain behind it.
There are historical parallels worth naming, because they calibrate expectations. Windows became dominant not by being the best kernel but by being the best platform — a surface on which third-party software could be distributed at near-zero marginal cost. The iOS App Store generalized the pattern for mobile, adding payment rails and a review gate. Kubernetes made the same move at the infrastructure layer with Custom Resource Definitions: anyone could extend the platform without the platform vendor's permission, provided they spoke the declarative manifest language. Stripe made it again at the business-process layer, turning payments — previously a business relationship with a bank — into an API-first product consumable by any developer in ten lines of code. In each case, the platform succeeded because it licensed a capability rather than selling an application, and because the licensing terms were machine-legible. SaaC is the same move, performed for organizational reasoning.
Objections and answers
I have heard every objection to SaaC. Let me address the three most common.
Objection 1 — "Our customers will not understand per-invocation pricing." True, for the first 12 months of the transition. True for consumer products forever. For enterprise B2B, customers already understand consumption billing (AWS, Snowflake, Twilio). SaaC pricing with sensible monthly-commit structures fits the same cognitive pattern. The transition requires a pricing page customers can simulate their bill on — which is easier, not harder, than traditional seat pricing.
Objection 2 — "We lose the predictability of ARR." Partially. SaaC pricing with commits plus overages is more variable than pure seat subscriptions, but the variance is narrower than it sounds — enterprise customers quickly hit their commits, overages are predictable within a quarter's lag. The upside: net-retention dynamics improve, because customers who get more value naturally consume more capabilities, and the revenue scales with the value.
Objection 3 — "Per-invocation pricing invites abuse." Correct. Which is why every SaaC capability must have cost guardrails at the caller side — per-user daily budgets, per-capability monthly caps, spike-detection — and cost visibility in the UX. Snowflake figured this out a decade ago for data warehousing; it is a solved problem with known patterns.
Two further objections deserve answers because they come up in architecture review rather than sales negotiation. "Isn't this just serverless functions with a pricing page?" — no, though a serverless function can be the kernel of a capability. The distinction is that a serverless function is invoked by name with arguments; a capability is discovered by manifest, negotiated for scope, bounded by guardrails, measured by outcome, and priced by invocation. A Lambda function has none of those properties by default. It is the difference between a CPU instruction and a library: both execute code, but only one is composable at the level of organizational competence. "Isn't MCP just JSON-RPC with extra steps?" — also no. MCP uses JSON-RPC as transport, as The Anatomy of a Capability and the Protocol Shift will elaborate, but it adds a discovery model, a session model, a capability-negotiation handshake, and a manifest contract. The relationship between MCP and JSON-RPC is the relationship between HTTP and TCP: one rides on the other, but the layer on top is where the semantics live.
The commercial effect on Nexcubator
In the book's narrative, Nexcubator converts from per-seat to SaaC over a 6-month transition. The immediate effect:
- Three customers churn out because their agents barely invoked Nexcubator's capabilities — they were paying for seats they did not use. Under SaaC, their bill drops by 70%; they realize they were over-paying and expand usage rather than leaving.
- Eight customers whose agents invoke Nexcubator heavily see their bills rise by 30–50%. Two push back; six accept because the per-outcome economics are obviously favourable to them.
- Two new customers sign — specifically because the SaaC pricing allows them to integrate Nexcubator capabilities into their own existing agentic platforms, rather than adopt Nexcubator as a destination.
Net: a slight short-term ARR dip, followed by a steeper growth slope. Customers expand by invocation, not by seat. The commercial shape matches the technical shape.
the diagram separates the four HR-Policy concerns every regulated industry has already asked SaaC to answer: identity (who is making the call), policy (what is and isn't allowed), provenance (where the answer came from), and auditability (can a regulator walk through this). These four concerns do not map one-for-one to a SaaS compliance posture because a SaaS compliance posture treats governance as a quarterly meeting. SaaC treats governance as a runtime program. The quadrant is the article's quiet thesis: the shift from seats to capabilities forces each of these four concerns to become a first-class runtime participant, and the four industries named underneath — finance, healthcare, insurance, public sector — are the early adopters whose regulators already demanded the posture a decade ago.
The finance team's internal reporting evolves alongside. Cohort analysis is re-cut by capability rather than by seat tier; net-retention is decomposed into per-capability expansion and contraction curves; the quarterly business review adds a slide showing which capabilities are gaining call-share against which alternatives. The sales compensation plan is restructured so that account executives are rewarded for capability landing — the first successful production call of a new capability inside an account — rather than purely for seat expansion. These are not small internal adjustments; they are the organizational reflection of the delivery-model change. A company that tries to run SaaC economics on a SaaS operating model will report the wrong numbers to its own leadership and make the wrong investment decisions.
Synthesis
SaaS solved distribution, operations, and iteration when the caller was a human. When the caller is an agent, SaaS assumptions break at every layer — the UI, the API, the pricing, the documentation, the integration posture. SaaC is the delivery model that matches the new caller: capabilities, not seats; manifests, not PDFs; invocation-priced, not flat-subscribed. Nexcubator's business model change from seats to capabilities is the concrete application. The next chapter formalizes what a capability actually is.
One final framing before we move on. The SaaS-to-SaaC transition is often described as a protocol shift or a pricing shift, and it is those things, but the deeper shift is in what the vendor is actually selling. A SaaS vendor sells access to an application. A SaaC vendor sells a slice of organizational competence — a piece of reasoning, memory, and guarded action that can be composed into any caller's workflow. The product is the capability; the application, if it exists, is one of several surfaces. Teams that internalize this inversion build differently, price differently, staff differently, and compound differently. Teams that do not internalize it build SaaS with a usage meter bolted to the side and wonder why their customers' agents never compose their products.
Keep reading
This article is part of The Software Lens — a weekly series on the architecture, commerce, and discipline of the agentic era. If it was useful, two things would help:
Pass it on. Forward this to one engineer or architect on your team who would benefit from a longer read than the LinkedIn feed allows.
Related articles
- The Anatomy of a Capability — The Anatomy of a Capability and the Protocol Shift
- Who Is at Risk — Who is at Risk Engineers vs Technicians in the Agentic Era
- Microservices Break, AIM Fits — Microservices Break and Aim Fits
About the author
I'm Imtiaz Hassan. I write The Software Lens about what software architecture becomes when the primary caller is no longer a human. The full long-form treatment of the ideas in this series — twenty-seven chapters, the SaaC delivery model, the AIM pattern, the Organizational AI Brain — is available as a paperback, hardcover, and Kindle edition on Amazon. The book →