The model
Software Delivery as a Service is a proposed operational, economic, and commercial model for consuming software delivery on demand. Its enabling hypothesis is that AI changes the cost of learning, producing, coordinating and deciding. If that change holds across the whole route to an accepted result, it could widen the range of demands for which bounded advances are useful to the buyer and sustainable for the provider.
This page explains the model once, from beginning to end, by following one demand. You do not need the vocabulary in advance: terms link to their definitions in the glossary as they appear.
The problem and the enabling hypothesis
Section titled “The problem and the enabling hypothesis”Delivering software starts well before code. Someone has to understand the request, explore alternatives, check constraints, prepare an offer, coordinate the work and judge whether the result is acceptable. These costs recur around every commitment, not just the first one. A demand can be perfectly feasible to build and still not justify the human effort of clarifying, coordinating and evaluating it.
The hypothesis is that AI can reduce the cost of this whole cycle, not only of one activity inside it. The order of the argument matters. A change in the economics of the work makes a different kind of consumption and production possible; the mechanisms described below make that possibility operable. Buying in stages or adding decision points does not, by itself, make it any cheaper to clarify, offer, execute and accept a demand.
What is bought
Section titled “What is bought”The customer buys a useful, bounded advance. It can be a clarification, a prototype, a feasibility analysis, an implementation or a deployment, whatever the need calls for, and the scope and conditions of each commitment must be recognizable to the person buying it. Completing a useful discovery can fulfil the service that was contracted without any application having been built.
What the customer receives is both a result and information. Clarified requirements, an evaluated prototype and known technical constraints support a more concrete offer for what comes next. The customer can accept it, ask for an adjustment, select a feasible part, defer or stop. Learning more does not, on its own, authorize spending more.
The relationship can be one person serving another, a company serving clients, or an engineering team serving other parts of its own organization, where budget authorization plays the role of the purchase. Scale does not define the model.
One demand, followed through
Section titled “One demand, followed through”A barbershop wants customers to book appointments online. It knows what it wants to stop doing, coordinating times by hand, but it has not decided every behaviour, and it has not bought a finished application. All amounts below are fictional and exist only to connect the mechanisms.
A first purchase: discovery. The barbershop buys discovery and solution design for 20. The work clarifies the rules: an appointment lasts 30 minutes, must fit within a professional’s registered availability, and cannot overlap another confirmed appointment for the same professional, while different professionals can work at the same time and a confirmed cancellation frees the slot. A prototype shows selection, confirmation, unavailability and cancellation. An architecture review identifies the calendar service that stores bookings and the need to prevent two simultaneous confirmations of the same slot. The barbershop keeps these results whatever it decides next.
An offer informed by what was learned. With discovery accepted, the provider offers to implement, validate and deploy booking for 80. Adding reminders would make it 95. Taking advance payments is left out of both offers because it still needs clarification.
A choice of scope. The barbershop chooses booking for 80. Selecting a part is possible here because booking works without reminders; reminders depend on bookings and are not offered as a standalone solution.
The same choice, delegated. The barbershop could instead grant a mandate: commit up to 90 more after discovery, provided stated technical and commercial conditions hold. An authorized system would select booking for 80. The alternative at 95 exceeds the mandate. The 10 left over remain unused authority; they do not buy part of a feature or anything undefined.
Production, a failure and a correction. During integrated validation, a test sends simultaneous requests and finds two overlapping confirmations for the same professional. The output breaks a rule that was already agreed, so the work returns to implementation under the same commitment, is corrected and evaluated again. Only then is the change deployed.
Other ways it could have gone. The barbershop could have stopped after discovery with its results in hand, asked for a revised offer, or deferred the decision. Each is a legitimate ending, and stopping after a fulfilled discovery is not a failure.
A familiar development flow offered through bounded commitments. The customer can buy discovery and design, then decide whether to authorize implementation and release. Stages exchange feedback, and commercial decisions follow the scope agreed rather than every internal task. This is a reference, not a sequence every demand must follow.
The complete case, with every commitment, rule, piece of evidence and alternative ending, is in intent to production and the example Delivery Unit.
How delivery stays understandable
Section titled “How delivery stays understandable”The model keeps a few things explicit so that everyone can tell what has been produced, what has been accepted and what has been authorized.
The demand itself is the continuing reference. A Delivery Unit represents a bounded demand, with its dependencies, while its interpretation changes. Its Delivery State records the current situation, so that “produced but awaiting evaluation” or “accepted but not yet authorized” can be told apart.
Work is organized as Delivery Stages: bounded transformations that take inputs and produce something that can be evaluated. Stages can return to earlier ones, run in parallel or stop; requirements, design, implementation and verification are common examples, not a mandatory sequence. Each stage works under a Stage Contract, the explicit conditions for the transformation: inputs, execution policy, expected outputs and acceptance criteria. “Contract” here names that specification; it does not mean a separate legal document for every stage.
Producing something is not the same as accepting it. Artifacts such as requirements, prototypes, code and tests are products of the work. Evidence is information that supports a judgment about them. A Quality Gate decides whether an output meets the agreed technical or quality conditions. That decision can be made by a person or by an authorized system; it does not require a human stop or a meeting at every stage.
How capacity is organized
Section titled “How capacity is organized”A stage says what must be produced and under which conditions. It does not say who produces it. An Execution Resource is a person, an agent or an arrangement eligible to do the work, and an Execution Policy sets the rules for eligibility, selection, autonomy and supervision. Separating the two means that human, hybrid and autonomous execution can all be judged against the same expected result. It does not make every executor equivalent: competence, context, access and risk limit what can be delegated.
The provider can share capacity across demands through Execution Pools, where specialists and agents serve parts of several projects, receive the context they need and return recognizable outputs to each demand. Whether sharing pays depends on the cost of preparing context, routing work, evaluating and resuming it. AI can help reduce that cost as well as perform the work, and dedicated resources remain a valid choice.
Together, coordination, execution, evaluation and continuity form the Software Delivery Engine. Engineering designs and controls the conditions under which it operates. That responsibility stays identifiable even on a fully autonomous path, and it does not require a person to intervene in every demand.
How commitment grows
Section titled “How commitment grows”Understanding a demand produces information, and the model keeps several related quantities apart.
| Concept | What it is | In the example |
|---|---|---|
| Estimate | The provider’s forecast of effort, cost, time and risk, revised as understanding changes | Revised after discovery; it informs the offer but is not the price |
| Offered price | The terms the provider is willing to assume, even with some uncertainty about its own cost | 80 for booking, 95 with reminders |
| Commitment | What the parties have actually assumed | Discovery at 20, then booking at 80 |
| Authorization | Who may commit, and up to what limit | The buyer directly, or a mandate of up to 90 more |
Progressive Estimation updates forecasts as context, artifacts and evidence change. More information does not always narrow a forecast: discovery can reveal a difficulty nobody knew about. Progressive Commitment expands or revises what has been authorized as the demand becomes better defined, and a new finding is never, by itself, permission to do more work.
The decision to commit is a Commercial Gate: continue, revise or stop. It is distinct from the Quality Gate. A design can be good enough to price and still not be authorized for construction. A Commercial Gate can be decided directly by the customer or by delegated authority, and the model does not require a new charge for every stage. It requires that each step stay within the current commitment and that any relevant change receive the right decision.
Limits and conditions of viability
Section titled “Limits and conditions of viability”The model asks three separate questions, and a good answer to one does not settle the next:
- Operational. Can the service repeatedly produce acceptable advances under its policies?
- Economic. Can the provider do so at a sustainable complete cost and risk?
- Commercial. Do buyers understand the service, buy it, and come back?
AI savings in one activity can be absorbed elsewhere, by evaluation, correction, integration, waiting, the upkeep of shared capacity, or extra effort from the buyer. An honest account of the economics has to include discoveries that end without construction. The barbershop example shows how the mechanisms relate to one another; it does not show market prices, margins or viability.
Paid discovery, contracting by delivery, staged commitment and shared capacity all have antecedents, and the model does not depend on claiming to have invented them. The bet is that AI changes the cost of sustaining them together, and so widens the set of demands that can be served and the frequency with which informed decisions can be offered.
Where to go next
Section titled “Where to go next”- Read why the model is proposed, from how software is delivered today to why AI changes the model.
- Follow the barbershop’s demand in detail, from intent to production, or read the whole case in the example Delivery Unit.
- See the ten design principles the mechanisms follow.
- Consider what would change if the model worked, in implications for organization, people, AI, scale and buying.
- Look up any term in the glossary.
- Read the paper, the citable statement of the model.
Software Delivery as a Service is a proposed model by Renan Deves and Marcelo Scheidt, Independent Researchers. See the paper for citation and license.