Software delivery today

Before discussing the proposal, it helps to look at the work it is about. This page examines how a need turns into usable software and how much work it takes, before, during and after implementation, to make that possible. Understanding the request, representing alternatives, forming conditions, coordinating decisions and recognizing the delivery all consume resources. That cost prepares the central question of the model: what could change in the way delivery is consumed when AI changes the economics of this route?

What “software delivery” means here

Software delivery starts with a simple relationship: someone needs a solution and someone develops software to meet it. A person can ask a developer for a small application; a business can contract a change to its system; one team can ask professionals in its own organization for work. Scale and formality vary, but in every case the request has to be understood, the work done, and what was delivered checked.

Here, software delivery means the work needed to turn a demand into software usable in the agreed context, whether by creating a solution or by evolving an existing one. That includes understanding the need, bounding what will be done, producing and checking the solution, making it available and establishing the conditions for operating it. Writing code is one part of that work. The delivery also depends on fitting the need and the conditions of use.

Take the hypothetical request “I want to keep track of my requests.” Even a small demand requires clarifying what information will be recorded, who can access it and what a completed request means. These decisions may fit in one conversation and be carried out by one person. The agreement can be informal, and it still has to guide what will be developed and how both sides will recognize that the request was met.

This distance between intention and result is what the model is about. It includes technical production, learning, coordination, and decisions about how much effort to spend. Context and responsibilities have to remain understandable throughout, whether between two people or across several organizations.

Two results must also be kept apart: making a software capability available, and producing the benefit expected from using it. An application can record and display requests correctly and still not help its user resolve them faster. That benefit depends on adoption, fit and conditions of use.

Three dimensions to keep separate

Delivery can be analysed through three questions: how the work is organized, how change is produced and made available, and how the economic commitment is established. They are related, but none determines the others.

The organization of work defines who keeps context, prioritizes demands, carries out activities and answers for results. One person can take on all of these; elsewhere they are spread across professionals, teams and organizations.

The flow of production defines how a change goes from a need to use. It includes discovery, implementation, evaluation, integration, release and learning. It can be iterative and allow returns, parallel work and interruptions; it need not be a rigid sequence of departments.

The economic commitment defines how much effort and how many resources will be dedicated, what will be charged when there is a contract, and under what conditions the decision to continue is made. Even without payment between the parties, dedicating time to one demand means putting other possibilities off. With a supplier, this shows up in the contract and the invoice; inside an organization, in budget allocation, opportunity cost and the choice between competing demands.

A team can work iteratively and be paid by time. A project can have a fixed price and use continuous delivery. An organization can fund a product persistently and make economic decisions per initiative. The commercial model cannot be inferred from the development method.

Ways of organizing and contracting the work

The table is a simplified analytical typology, not a measurement of the market. Arrangements coexist, and a real contract can combine features of several rows.

Arrangement	What organizes the commitment	Question it has to resolve
Individual development on request	An agreement between the person who needs the solution and the person who builds it	How to clarify the request, agree effort or price, and recognize the delivery?
Staff augmentation	Providing professionals with certain competences	How to integrate that capacity into the context and responsibility of whoever receives the work?
Time and materials	Paying for time and resources used	How to control spending, progress and priority without assuming a fully known scope?
A contracted team	Collective capacity kept for a period	How to turn continuity and competences into relevant deliveries?
A project with agreed scope and price	A commitment to deliveries, conditions and limits	How to handle interpretation, changes of scope and later discoveries?
A persistent product team	Continuous responsibility for a product	How to compare new opportunities and keep up evolution and operation?
A managed service	Recurring responsibility bounded by service conditions	How to define boundaries, performance, and changes that go beyond the service?

These arrangements answer different needs. Bounded work can be done by one person; evolving a product may need recurring dedication; a service can involve continuous operational commitments. Contracts can also pay for time, agree a price per delivery, buy discovery separately, or make payments conditional on acceptance. To understand a delivery relationship, one has to identify which commitment was made and how it will be revised when new information appears.

What delivery already tries to solve

Learning, adaptation and improving delivery are already part of existing approaches. The principles behind the Agile Manifesto call for collaboration and frequent delivery; the Scrum Guide and The Kanban Guide contribute ways to inspect work, adjust decisions and improve its flow. Continuous Delivery describes the ability to release changes safely and sustainably by keeping software releasable. It concerns delivery capability; it does not, by itself, define the unit a customer buys or the moment a demand is commercially authorized.

The question here is how to link the progression of a demand, the carrying out of the work, and the commitments of the person asking and the person building. Flow, learning and explicit policies are antecedents of that inquiry. Their presence alone does not establish that the proposal is original, and the model does not depend on any particular method.

Where a demand meets the constraints of the operation

A demand can require decisions about effort before its content is well bounded. The builder has to assess the work and their availability; the person asking has to decide whether the solution is worth the resources. This can happen in a conversation between two people or in a formal budget process.

Dedicating time and interrupting existing priorities costs something. The difficulty appears when a commitment has to be made in order to produce the information that would allow it to be evaluated. The builder needs to understand in order to estimate; the buyer needs some estimate in order to decide; understanding already takes work.

This tension has several known responses: paid discovery, staged contracts, spending limits, replanning, or persistent funding. They are relevant antecedents. An investigation can be bought precisely to produce the information for a later decision, without the customer committing to the whole construction at first contact.

That work has a cost of its own. Someone has to interpret the need, investigate alternatives, produce a representation of the solution and form conditions for continuing. Even when the final implementation is small, this initial effort can be significant for both sides. The time spent clarifying and deciding is part of the experience of consuming software.

Consider a demand whose potential benefit justifies a small implementation, but not the effort of several interactions to understand it, assess it and offer conditions for carrying it out. In this hypothetical case, splitting the purchase does not remove the barrier by itself, because preparing each decision also costs something. The parties can group work, accept more uncertainty, or drop the demand. The economic boundary depends on the cost of making the next commitment understandable and executable, not only on the cost of writing the software.

The question behind the model is under what conditions this route could be offered as a recurring service: arrive with an intention, buy a useful advance, and use what was learned to decide on the next commitment. The role of AI in that possibility is the subject of the next page.

In which contexts is this tension actually the dominant problem? An internal team with continuous demand may handle uncertainty well through its product budget. A customer with occasional changes may need more visibility per delivery. The model should not assume both buy or govern software in the same way.

An example between companies

Between companies, the same questions can involve more participants and dependencies. An industrial company hires a software supplier to add approval by spending limit to its purchasing portal. The procurement team presents the need; IT states integration and security constraints; the supplier leads the detailing and proposes the solution. Authorization to spend lies with an authorized person at the client, who may differ from the person who validates that it works.

In the first conversation, the demand looks like a routing rule by amount. During clarification, limits per business unit appear, along with different currencies, temporary substitution of managers and requests already in progress. The prototype reveals the need to explain to a requester why a request is waiting for approval. Technical analysis finds that the ERP provides some of the data in batches, not in real time.

Client and supplier then have to decide whether the first delivery will accept that delay or include a new integration. The choice changes scope, acceptance criteria, cost and time. The supplier presents the consequences; the client weighs the priority and authorizes the corresponding commitment. The demand has gained information, but it has not necessarily become smaller or cheaper: an updated estimate can rise even though it is better founded. Evidence and cost reduction are not the same thing.

If the contract pays for time, these discoveries can change priority and budget consumption. If it fixes scope and price, they may require interpreting what was included and negotiating a change. If it keeps a dedicated team, they may lead to reprioritizing the backlog with the client. The example makes visible decisions that also exist in smaller work: what has been understood, what remains to clarify, what will be delivered and how much effort will be authorized.

Capacity, delivery and economic responsibility

Capacity is the possibility of carrying out work under certain constraints. Delivery is what was produced and accepted. Business effect is a consequence of use. Keeping these objects apart is necessary to ask what is being bought and which risk remains with each participant. Paying for capacity does not mean giving up on results; an organization may buy specialists’ time precisely because it cannot define the best solution in advance. And paying for a delivery does not remove the risk of buying something that does not produce the expected benefit. See from capacity to outcomes.

The starting point

The starting point is the transformation of a need into usable software. The person asking and the person building have to build understanding, make choices and recognize the delivery. People, teams, projects and contracts are ways of organizing that relationship under different conditions. The examples on this page are illustrative; this is a conceptual analysis, not a representative survey of the market.

Next: why AI changes the model.