When SaaS pricing becomes infrastructure policy

Software pricing is conventionally treated as a procurement concern. It is negotiated by finance and vendor management, recorded as a recurring line item, and reviewed at renewal. The technical organization inherits the outcome without generally regarding the contract as an architectural document.

This paper asks a narrower question. What happens when the unit being priced — users, transactions, data, hosts, requests, features or consumption — is also something the organization must make continuous operational decisions about?

The premise is not speculative. Microsoft’s Azure Well-Architected Framework guidance for SaaS workloads states directly that the business model and pricing strategy of a SaaS solution are linked to its architecture, and that billing and pricing decisions influence solution design (design methodology; billing and cost management). That guidance is written for the vendor building the platform. This paper considers the same relationship from the other side of the contract: what a commercial model does to the buyer’s decision environment.

A commercial meter is a rule that converts an activity into a cost. AWS Marketplace documentation for SaaS products describes pricing that can be structured around dimensions such as users, hosts, requests, bandwidth, data and other units of usage (SaaS product pricing). Those dimensions are not accounting abstractions. Each one names something an engineering or operations team already manages.

A pricing dimension is a statement about which operational activity is now visible in the finance system.

This is where the System Drift interpretation begins. Once a commercial meter is attached to an operational activity, increasing that activity has a visible financial consequence. That does not automatically change what an organization does. It creates an economic signal — one input among many — that the organization may or may not respond to. The significance of the signal depends on how large the cost is relative to the decision, how quickly it is attributed, and who is accountable for it.

The analytically important point is that the choice of dimension is not neutral. Two products with identical functionality and identical annual cost, metered differently, present the buyer with different questions. One asks how many people should have access. The other asks how much data should move.

Per-user pricing — listed among the dimensions AWS Marketplace supports for SaaS products (SaaS product pricing) — makes each additional participant in a system an explicit, recurring marginal cost.

The structural question follows: when every additional participant carries a recurring cost, can licensing economics begin influencing who receives access to organizational systems?

System Drift treats this as an open analytical question rather than a documented outcome. We have not observed, and do not claim, that organizations systematically restrict access for licensing reasons; we have no public evidence that would support such a claim, and we decline to invent examples. What can be stated is structural: under a seat meter, the decision to extend a system to an additional team, contractor or function is evaluated against a price, whereas under an organization-wide meter it is not. Where a decision carries an explicit marginal cost, it can also acquire an approval threshold that would not otherwise exist.

Consumption pricing meters activity rather than headcount. The AWS Marketplace documentation describes usage-based SaaS pricing across dimensions including data, hosts, requests and bandwidth (SaaS product pricing), and Microsoft’s Well-Architected guidance for SaaS workloads addresses the measurement, metering and cost-management machinery such models require (billing and cost management).

The documented fact is that these models exist and that they require the metered activity to be observed. The System Drift interpretation is what follows from that requirement: an organization operating under a consumption model must build the capability to watch the activities that create cost, and once that capability exists, those activities are legible to people who did not previously see them.

Architecture, workload scheduling, data movement and usage patterns can become financial decisions as well as technical ones.

Whether that is good or bad is outside the scope of this paper. Cost visibility is frequently useful. The structural observation is only that the set of considerations applied to a technical decision has widened, and that the added consideration is supplied by the supplier’s commercial model rather than by the organization’s own engineering priorities.

Microsoft’s Well-Architected guidance for SaaS workloads describes billing tiers that can differ in functionality, performance characteristics and deployment model, and discusses enabling or disabling features according to a customer’s billing plan (billing and cost management; design methodology).

The structural implication is that commercial packaging can determine which technical capabilities are practically available to an organization. A capability that exists in the product but sits behind a higher tier is, for planning purposes, a capability the organization does not have — until the commercial position changes.

Two claims are deliberately not made here. First, that higher tiers are inherently better: tiering is a normal way of matching price to scale, and most organizations do not need most of what sits above them. Second, that vendors design tiers in order to create dependency. This paper is about structural incentives, not vendor intent, and nothing in the cited documentation speaks to intent.

Commitment introduces a different mechanism. AWS Marketplace documents SaaS contracts, in which a buyer agrees in advance to a quantity of usage for a contract term (pricing for SaaS contracts). Salesforce publicly describes flexible buying models including pay-as-you-go, pre-commitment and pre-purchase arrangements, and states that savings increase with the size of the commitment (flexible buying models).

Those are the documented facts: prepaid and committed models exist, and at least one major vendor states publicly that larger commitments carry larger discounts.

Microsoft’s Well-Architected guidance for SaaS workloads also discusses commitment discounts, noting that consolidating customer resources can help a SaaS provider qualify for commitment-based discounts (billing and cost management). That is written from the vendor’s perspective; it does not describe buyer behaviour. It does, however, document a direct relationship between commitment economics and resource consolidation.

The System Drift analysis is about what a commitment does to the buyer’s next decision. Once an organization has committed financially to a quantity of platform usage, consuming more of that already-purchased capacity may become economically attractive compared with introducing another supplier — because the marginal cash cost of the committed platform has already been paid, while the alternative requires new spend, new procurement and new onboarding.

A prepaid commitment does not forbid a second supplier. It can make additional use of the existing platform appear economically preferable because part of that capacity has already been purchased.

This is presented as analysis, not as a universally observed behaviour. Organizations weigh many factors, and some deliberately diversify at a premium. But this is the point in the mechanism where pricing can begin contributing to supplier concentration, which is the subject of F·01 Dependency Concentration.

Taken individually, each mechanism above is modest. A seat price adds an approver. A usage meter adds a dashboard. A tier boundary defers a capability. A commitment tilts one comparison. None of them determines anything.

Pricing becomes infrastructure policy when commercial terms repeatedly influence the same class of decisions:

• who receives access to organizational systems;
• which features are deployed;
• where workloads run;
• how usage is controlled or throttled;
• whether another supplier is introduced at all;
• how much additional activity is consolidated onto an existing platform.

The distinction that matters is this: a pricing model does not need to formally dictate architecture in order to influence it. Repeated economic incentives can gradually narrow the set of choices that appear operationally reasonable. Nothing is prohibited; some options simply stop being proposed.

This is the accumulation pattern described in R-001, arriving through the commercial layer rather than the integration layer, and it bears on F·02 Reversibility because choices that were never made are also choices that were never kept open.

This is not advice about negotiating contracts. It is a short set of questions that make the mechanisms above visible inside a specific organization.

• What operational behaviour does our pricing model actually meter?
• Which decisions become more expensive as usage grows?
• Which capabilities exist in the product but only at higher commercial tiers?
• What commitments have already been prepaid, and until when?
• Does existing commitment make consolidation appear artificially cheaper than diversification?
• Would changing supplier require changing operating behaviour as well as contracts?
• Are procurement decisions creating technical assumptions that will survive beyond the current contract?

Software pricing is usually negotiated as a commercial arrangement. Its effects do not necessarily remain commercial. When the units being priced correspond to users, workloads, data, features or infrastructure, the pricing model becomes part of the environment in which technical and organizational decisions are made.

Read alongside System Drift’s wider themes, this suggests a quiet route to dependency. Dependency can accumulate not because an organization consciously chooses deeper dependence, but because repeated economically rational decisions gradually align operations with the commercial structure of the platform. That is a plausible mechanism, not a demonstrated law, and it should be held as such.