From capacity to outcomes

Someone who needs software is looking for a way to meet a need. They can hire a professional’s time, fund a team, or agree on the delivery of a solution. Each choice sets up a different commitment between the person asking and the person building.

The previous pages presented AI as a possible enabler of a change in the economics of understanding, producing, evaluating and coordinating, a change that could make it viable to offer smaller advances with understandable conditions. This page looks at the consequence for consumption: is the buyer purchasing capacity to execute, an identifiable delivery, or a benefit that comes from use? Understanding the difference is necessary to formulate the service without attributing to software promises it cannot keep on its own.

What is bought when capacity is bought

Buying capacity means obtaining the conditions to carry out work: a few hours of a developer to investigate a problem, or professionals kept available to evolve a product. The agreement provides access to competences, availability and effort, under certain conditions.

That can make sense when the right solution is not yet known, or when the need is continuous and the value lies in being able to decide over time. Buying capacity preserves that flexibility, as long as both sides understand how the work will be directed and followed. The desired result still matters; the difference is that capacity does not, on its own, determine which delivery will be obtained. The buyer takes part in decisions about priority, scope and the use of the available effort.

Buying capacity is not a mistake the model needs to correct. It is one way of organizing commitments. What is being investigated is when a demand can be expressed and met with more emphasis on what will be delivered, without requiring the requester to define in advance all the resources production will need.

When the delivery guides the commitment

In a delivery-oriented commitment, the parties make explicit what will be produced and under which conditions it will be acceptable. The conversation about resources continues, but now in support of that commitment. For the request “I want to keep track of my requests,” buying capacity might mean reserving time to develop and adjust the application. Agreeing on a delivery might mean making available a solution in which certain users can record requests, check their status and see when they are completed, with conditions of access and use defined. That still leaves execution decisions to the builder: the requester needs to understand what they will receive, not choose every tool or estimate every activity.

This does not depend on a single form of payment. A delivery-oriented commitment can include paid stages, spending limits or revisions of scope, and a fixed price does not by itself show that the delivery is well defined.

The word “outcome” can hide very different commitments. A working application is a result of development; spending less time organizing requests is a benefit expected from using it. The model keeps capacity, delivery and benefit of use explicitly apart; the definitions and what each one requires are on Outcomes.

Buying the advance that allows a decision

Orienting the commitment by delivery does not require knowing the whole solution at the first conversation. A person can buy a first advance whose result is to clarify the need, investigate feasibility or represent alternatives. That work is already part of the service consumed.

The advance has an identifiable purpose. A prototype lets interactions be evaluated; a set of requirements bounds behaviours; a technical analysis clarifies integration and constraints. Its usefulness depends on how well these outputs serve the next decision, including when the decision is not to build.

Progression connects learning and buying. With better information, the provider can form conditions for continuing and take on a better-defined commitment; the buyer can compare that commitment with the need and the resources they intend to spend. The route can gather several transformations in one offer or make advances available separately.

If producing that information costs little relative to the decision it improves, the parties can discover what the next commitment needs without requiring all the detail in advance. The AI hypothesis is precisely to widen the contexts in which that relationship holds. The customer can compare a broader solution with a simplified alternative and their respective prices. Reducing scope or complexity has to preserve a viable delivery; describing the same solution more briefly does not reduce its work or its risk.

This does not guarantee that the next price will be lower or that all uncertainty will disappear; discovery can reveal greater complexity. It can still make the decision better founded. An intermediate delivery has its own acceptance criteria: if what was bought was to investigate and present alternatives, meeting that scope can conclude the commitment successfully even without any later implementation. That is different from abandoning construction already contracted, or claiming that a prototype is software in production.

A route of progressive consumption

A barbershop wants its clients to book appointments. In the hypothetical example, it first buys the clarification of the need and the design of a solution: booking rules, a prototype and an analysis of how it relates to the existing calendar. Construction is not yet authorized.

The work separates three possibilities: booking, reminders and advance payment. It identifies dependencies and makes it possible to present an offer for booking and additional conditions for the rest. The provider stands behind the commitment it offers; the price is not a statement of exact knowledge of every future cost. The customer decides to start with booking. Reminders are left for later, and advance payment returns to analysis because it depends on choices still open. The partial approval respects dependencies: a part can be handled separately only when the resulting scope remains feasible and understandable.

Moment	What can be bought or received	Possible decision
Initial intention	Bounded clarification and design	Authorize the first advance.
Definition produced	Rules, prototype and technical analysis, evaluated	Ask for adjustment, or recognize the purchased output.
Offer to continue	Conditions of scope, price and delivery	Approve all, select a feasible part, defer or decline.
Construction authorized	A feature according to the commitment chosen	Follow and evaluate the delivery, directly or by delegation.
Closing	The outputs and obligations of the contracted scope	Conclude the commitment and decide on a new demand.

The customer could also conclude with discovery alone and use its outputs under the agreed conditions; the usefulness of that result does not depend on buying the next step. A prior authorization could let the service decide on continuing within limits of scope and budget; the decisions still exist, but they do not need the customer at every step. The degree of delegation and the human or automated composition of execution are related but distinct choices. A relationship between companies, like the approval flow in an industrial purchasing portal, can follow the same logic with more participants and dependencies.

How AI could widen the viability of this kind of consumption

Offering this route requires the capacity to clarify, produce, evaluate, decide and coordinate. The hypothesis is that AI could change the economics of that capacity: make certain investigations more affordable, allow cycles of attempt and correction, reduce some of the waiting for decisions that can be delegated, and support reusing configurations for new demands.

If those effects hold, the service could serve requests that used to be unattractive because of the cost of preparing and coordinating them. The change could appear as a more accessible entry point, offers formed with less latency, or the capacity to serve new demands without proportionally increasing all human work. It has to be verified across the complete route: preparation, infrastructure, review, failures, corrections, later obligations and the buyer’s effort. A hybrid operation can realize the hypothesis; full autonomy is not required of every service.

The delivery commitment gives a reference for consuming that capacity without buying a fixed composition of resources in advance. The commercial experience depends on the capacity to produce; its viability does not come from a new way of charging alone. Different pricing arrangements can coexist, and buying by time remains possible.

Conditions and limits

A delivery orientation has to make its scope and acceptance conditions understandable, and it has to tell a correction needed to meet the agreement apart from a change to the agreement itself. If the parties give different meanings to the expected result, the apparent precision of the contract only postpones the conflict. Dependencies matter too: if a change depends on information or adjustments controlled by the client or another supplier, the commitment has to say what each party provides and what happens if that condition is not met. The same care applies after deployment: operation, support and evolution need understandable boundaries.

These requirements add work of definition and evaluation. A delivery orientation is useful when that effort produces better commitments and clearer decisions; in simple situations, the agreement can stay brief.

The hypothesis the foundations allow

The foundations start from the relationship between the person asking and the person building, examine the enabling role of AI, and propose preserving intention, context and commitments while execution varies. That base allows a service experience to be formulated: buy an advance, learn from its outputs, and decide on the next commitment, with production coordinated by the provider.

The hypothesis is that AI will make it economically viable to offer that experience for growing portions of software demand. The object consumed is the useful, recognizable advance, with its conditions and obligations. Three questions remain to investigate: whether the operation can fulfil the commitment, whether it can do so sustainably, and whether buyers choose it repeatedly. A technical demonstration does not answer all three. The examples are illustrative; a delivery orientation and the benefits attributed to it are conditional hypotheses, and this page proposes no contract clauses and demonstrates no economic results.

The model organizes the elements that support this experience. For how the object of consumption can shift in practice, see from hours to outcomes.