4. Pricing what the customer assembles

Seat and tier pricing has long been the dominant SaaS model. A customer buys a tier, the tier bundles a common set of capabilities, and the price is set by some measure of use of the application as a whole: per user, per agent, per tenant. A customer support product sold per agent per month in escalating suites is a typical example (Zendesk pricing, accessed September 2026). The price follows the tier, whether or not this customer needs everything in it.

Customers pay for a good deal they do not use. Pendo's analysis of feature usage across 615 of its own customers' products found that 80% of features in the average software product are rarely or never used (The 2019 Feature Adoption Report, Pendo). At the level of whole licences, Zylo's 2026 index reports that organisations leave an average of 36% of their SaaS licences unused (2026 SaaS Management Index, Zylo, January 2026).

The market is already moving away from the seat. In a 2025 survey of more than 240 B2B software companies, the share whose primary model was seat-based fell from 21% to 15% in a year, while hybrid pricing rose from 27% to 41%. Only 5% priced primarily on outcomes, and 25% expected to by 2028 (The State of B2B Monetization in 2025, Poyar, June 2025). Agents accelerate the move. Bain puts it directly: "Seat-based pricing may not fit when AI is doing the work" (Will Agentic AI Disrupt SaaS?, Bain, 2025). Gartner estimates up to $234 billion of enterprise application spending exposed to agents completing work across systems by 2030, and notes that this "breaks the link between user growth and revenue growth for many enterprise software vendors" (Gartner, July 2026).

4.1 A bill of materials for software

Section 2 describes a product in which each customer's implementation is a document composed from shared domain primitives. That document is, in effect, a bill of materials: a list of the capabilities this customer's implementation uses and how they are put together. It makes a different pricing model available, closer to how modular physical products are priced.

Manufacturing builds product cost from two parts. The bill of materials lists every component and raw material that goes into an assembly, and standard costing calculates the cost of a manufactured item from it (Information used in BOM calculations with standard costs, Microsoft, 2025). Conversion cost, the direct labour and overhead of turning materials into a product, is added on top (Accounting for Managers, Lumen Learning). Modular products extend this to variety: with a modular architecture each function maps to a component with a de-coupled interface, so product variety comes from combining components (Ulrich, Research Policy, 1995). In configure-to-order selling, the customer chooses a base model and selects options, and the price is calculated from the configuration itself rather than looked up on a price sheet (Configurator glossary, Oracle; What Is CPQ?, Oracle NetSuite, 2025).

Three things follow. A customer pays for the capabilities its implementation uses, which addresses the unused-feature problem directly. The assembly work that onboarding and configuration currently bury inside a tier becomes a visible, priced service. And because the price is computed from the same document the compiler validates, the quote and the implementation cannot drift apart.

4.2 Material and assembly

The assembly cost has fallen, which is the premise of this paper, and it has not fallen to zero. Someone still maps a customer's requirements onto the domain, reviews what an agent composes, runs the case corpus and handles change requests. Pricing that work separately makes its cost legible to both sides. It also changes how the work scales: under a tier, a customer with complex requirements and a customer with simple ones pay the same and cost very different amounts to serve, whereas under material-plus-assembly each pays for what its own implementation took.

4.3 Where the value sits

Pricing components alone carries a risk that physical products have long had to manage. What the customer values is what the assembled whole does, and a component price can under-price that. Value-based pricing sets price by "the value a product or service delivers to a predefined segment of customers", and Hinterhuber's review of pricing research finds that cost-based pricing "leads to lower-than-average profitability" (Hinterhuber, Journal of Business Strategy, 2008). Bundling theory adds that a well-designed bundle can capture value that separately priced components leave on the table (Bakos and Brynjolfsson, Bundling Information Goods, 1996).

Physical products handle this with packages alongside components. Vehicles are sold as trim levels and option packages as well as individual options, partly because, as one industry analyst put it, "If you allowed everything to be a separate option, the possible configurations of a vehicle would explode exponentially" (Sticker Shock: Navigating Car Trim Levels, Consumer Reports, 2018). The same applies here. A capability catalogue can carry composite SKUs, pre-assembled for common domain scenarios and priced on the value of the scenario, next to the component SKUs they are built from. Because both are expressed in the same language, a composite SKU is itself a document, and the compiler can price and validate it in the same way.

4.4 Outcome-based pricing

For AI agents the market is moving toward pricing by outcome. Intercom charges $0.99 per outcome for its Fin agent, on top of a base plan (Fin pricing: Outcomes, Intercom). Salesforce launched Agentforce at $2 per conversation (Salesforce Unveils Agentforce, September 2024) and added per-action pricing at $0.10 per action in 2025 (Salesforce, May 2025). Zendesk announced pricing that charges only for issues its AI agents resolve autonomously (Zendesk, August 2024).

Outcome pricing and capability pricing measure different things and combine well. Capability SKUs price what a customer has assembled and made available. Outcome or usage metering prices what that assembly then does, for the capabilities where the work performed varies. The domain document helps with both, because it records which capability is in play when an outcome is produced, which gives a basis for deciding which outcomes are metered and how they are attributed.

4.5 Pricing a plugin

A customer-scoped plugin (section 15) is the equivalent of a part made to order: built for one customer, maintained for one customer, and costed accordingly. That customer pays for its build and upkeep, as an assembly-heavy line on its bill of materials. When the need recurs and the plugin is generalised into a shared primitive, it becomes a catalogue SKU available to every customer at catalogue price. The customer carrying a plugin therefore has a reason to want it generalised, and the vendor has a pricing signal telling it which plugins to promote first.