Procurement
The proposed experience starts before any specification exists. Someone presents an intention, can buy a useful discovery, and receives information to choose the next commitment. The implication for procurement is to compare advances, responsibilities and conditions for continuing, without having to organize the means of production continuously. The decision can be direct or delegated, and it does not require a purchasing department.
What is being bought
Section titled “What is being bought”The first question is what the relationship offers. Availability of people, consumption of resources, a bounded delivery and an observed business effect are not equivalent objects. An offer must make the result, its limits and its acceptance conditions recognizable; the phrase “software delivery as a service” on its own says nothing about price, time, responsibility or scope. A simple relationship between the person asking and the person building already involves these decisions, briefly; in larger organizations, different teams may take part in definition, evaluation and economic authorization. What matters is comparing understandable commitments, with participation proportional to the work and the risk.
Comparing offers on the same scope
Section titled “Comparing offers on the same scope”Two offers can have different prices because they cover different results and responsibilities. Comparing only the total or a rate per resource can hide that. One offer may include clarification, integrated evaluation and deployment; another only implementation from specifications the buyer supplies. The comparison must recognize the work that stays with the buyer or with third parties, and how dependencies and corrections are treated. That does not mean requiring identical offers: alternatives can distribute work and uncertainty differently, and the buyer should understand those differences before treating them as price variation for the same service.
Questions for examining an offer
Section titled “Questions for examining an offer”These are questions about the operational and commercial proposal, not contract clauses, and they do not replace an organization’s own processes.
| Question | What must be understandable |
|---|---|
| Result | What will be delivered, and what stays out of scope? |
| Acceptance | Which criteria and evidence support recognizing the delivery? |
| The buyer’s part | Which decisions, information, access and evaluations must the buyer provide? |
| Execution | What freedom does the provider have, and which limits apply? |
| Continuity | How are dependencies, corrections, changes and interruptions handled? |
| Responsibility | Who answers for the commitment, and who can decide each question? |
| Price and consumption | What is charged, under what conditions, with what limits? |
| Artifacts and transition | Which information and outputs remain available for use and continuity? |
The answers should relate to the service offered. A long description of tools does not show how a divergence will be resolved or who can accept an output, and a catalogue of promises is no substitute for information on how the commitment will be carried out.
Buying learning, then choosing what continues
Section titled “Buying learning, then choosing what continues”Progressive Commitment makes it possible to buy a discovery with its own price, outputs and acceptance. The buyer receives something usable, such as requirements, a prototype and architecture decisions, and information that helps compare alternatives. That output must be useful even if construction is never chosen.
What enables this experience is being able to produce the learning and prepare the decision at a cost the first advance can sustain. AI could reduce the work of asking questions, exploring alternatives, producing prototypes and checking constraints, allowing depth proportional to the next choice. Commercial freedom does not come from dividing a budget into instalments; it depends on an operation able to deliver those useful portions.
The buyer can then discuss scope and investment together: including an integration or a more demanding operating condition can raise the price; removing unnecessary complexity can lower it. That needs concrete alternatives and matching offers. Leaving out needed detail does not simplify the solution and can raise uncertainty and exposure. The provider uses what was learned and Progressive Estimation to form the next offer. An estimate is a forecast under assumptions; a price is a proposed condition; a contract assumes obligations. A more concrete figure is neither a certain cost nor an automatic authorization.
The buyer can accept the whole offer, choose an independent part, ask for adjustment, defer, or stop after discovery. A partial approval must preserve dependencies and criteria, and removing a part may need a new offer. Fulfilling discovery without buying construction is not a failure of the service. These choices can happen in an assisted interaction, self-service, or through a system under mandate, as long as scope, evidence, price and alternatives are presented usably, with recognizable authority and balance. One commitment can group several transformations; progression does not require a purchase per activity.
The conditions of use and continuity of artifacts matter too. Another provider may need preparation to use them. The service should not equate handing over documents with free portability, nor turn the first purchase into an implicit obligation to build with the same provider.
Freedom of execution and the use of AI
Section titled “Freedom of execution and the use of AI”A delivery-oriented offer can let the provider choose the composition of resources within agreed conditions, compatible with access, information, evaluation and responsibility. Using agents is not an automatic guarantee of a lower price or higher quality; the offer should explain the conditions relevant to the delivery, including supervision and how inadequate results are handled. At the same time, requiring a fixed number of professionals may not fit a delivery commitment when the operation allows other compositions. A buying decision has to distinguish a requirement on capacity from a requirement on result. Both can coexist: a buyer may want dedicated availability for some needs and bounded deliveries for others.
Acceptance and economic decision
Section titled “Acceptance and economic decision”The Quality Gate supports technical or quality acceptance; the Commercial Gate decides on economic continuation. The buying relationship has to identify the authority and scope of each, direct or delegated. A system can approve continuation for the buyer within explicit preferences and budget, but that mandate is not the provider’s mandate to form offers, nor the environment’s permission to deploy software; see Mandates. An economic authority can approve resources without the information to accept an implementation, and whoever validates a business rule may not have authority to raise the budget. Payment follows the agreement but must not silently change what acceptance means: a payment does not show technical fulfilment, and an accepted output does not prove an economic benefit.
Dependencies and participation during the service
Section titled “Dependencies and participation during the service”The buyer may stay responsible for clarifying rules and providing conditions, while delegating decisions represented in a mandate. The aim is to reduce the coordination they have to do, including routing work between specialists, with clear treatment for whatever the service cannot yet decide. If continuing depends on a decision, the provider has to present the question usably, with context and consequences. Waiting can affect time and consumption; how it is treated depends on the agreement, without assuming all waiting is free, billable, or caused by one party. An identified dependency should guide coordination and a review of the commitment, not become a generic excuse for delay.
Change, interruption and continuity
Section titled “Change, interruption and continuity”An additional request is compared with the scope in force: correcting a divergence from an accepted criterion is not the same as widening the expected result. Progressive Estimation shows the effects of a change without setting an extra price or authorizing execution. An interruption requires dealing with work done, effects and remaining obligations; artifacts can make continuation easier without removing the cost of transfer. An offer should make it possible to understand how the service preserves context, decisions and outputs, in what format they can be made available and under which conditions of use, including third-party restrictions. That helps examine operational dependency, without promising unrestricted portability or legal conditions the model does not set.
In the running example
Section titled “In the running example”Discovery C0 costs 20 fictional units. Its artifacts support an offer C1: booking for another 80, with reminders as an option for 15 more, 95 in total. These are illustrative prices, not production costs, market prices or payments made.
The buyer can choose booking alone because it works independently. Under a mandate of up to 90 more, choosing 80 leaves 10 authorized and uncommitted; the combined offer at 95 exceeds the mandate. Adding the 20 for discovery, the contracted price is 100 under an aggregate ceiling of 110. The balance of 10 cannot automatically fund a different obligation and is not money in an account. If the buyer does not want to build, the accepted discovery remains a fulfilled commitment; if they want another rule or a different combination, the provider examines dependencies and presents revised conditions.
To compare providers, the buyer needs to know whether the 80 include implementation, integrated validation and deployment under the defined conditions, or only code to be integrated. A lower offer can move work onto the buyer; a broader one may still depend on the buyer’s access. Comparing total effort and scope is more informative than comparing the headline number.
How to decide, and the limits
Section titled “How to decide, and the limits”A choice can weigh the fit of the result, the capacity to evaluate, responsibility, total cost and conditions for continuing, in proportions that depend on the demand. Pricing and Unit Economics help separate the price offered, the consumption of the service and sustainability, and the buyer has to count their own effort, without assuming it is all included in the provider’s offer. A commitment tied to business benefit needs extra conditions for observation and attribution: receiving accepted booking is not receiving a proven reduction in missed appointments.
The commercial signal to watch is whether buyers understand the options, buy useful advances with less effort, and come back. Conversion to construction on its own is the wrong measure, since discovery can show that stopping is the best decision. Comparisons should include understanding of the commitment, time to decide, the buyer’s work and the usefulness of the intermediate output. How to compare heterogeneous offers and limit the cost of evaluating a purchase remain open. This page raises conceptual questions about acquiring the service; it is not legal guidance, a contract model, a regulatory rule or financial advice for any specific purchase.
Software Delivery as a Service is a proposed model by Renan Deves and Marcelo Scheidt, Independent Researchers. See the paper for citation and license.