Software Delivery as a Service

A proposed thesis, not a measured result

Why this was out of reach before

The main enabler is not AI writing code faster. It is AI lowering the cost and time of the whole cycle between an intention and an accepted advance: understanding the request, investigating, proposing, experimenting, building, verifying and preparing the next decision. That change may make it economically viable to offer smaller parcels of delivery.

Six capabilities, in causal order

  1. From an incomplete intention to executable work. AI can help ask questions, examine existing systems, compare alternatives and produce a first specification or prototype. Repeating that human effort for every small demand used to cost more than the advance justified.
  2. Cycles of attempt and correction. Agents can already use tools, change code, run tests and review their own attempt. That extends automation beyond procedures programmed in advance, although reliability still varies a lot with the task. METR
  3. Useful information before committing to the whole build. Discovery, technical analysis and prototyping can become advances worth contracting on their own. The client can learn, pick a smaller version, move on to implementation or stop. AI did not invent paid discovery; the hypothesis is that it may make it affordable for more demands.
  4. Evaluating and repeating with less waiting. Tests, explicit criteria and analysis of results can feed new correction cycles. Some passes may run autonomously; others will need specialist evaluation. The gain depends on the quality of that verification, not only on the speed of production.
  5. Preserving and transferring context between executors. If intention, decisions, artifacts and delivery state are usable by people and agents, a demand can move through specialized resources without rebuilding everything at each handoff. That may make pools serving several demands viable, but the coordination cost has to be measured.
  6. Lowering the cost of preparing the next offer and decision. After an advance, the service can update alternatives, risks, scope and price from what it learned. The client decides directly or delegates some decisions within set limits. Progressive commitment then stops requiring a heavy negotiation at every small step.

A factor that cuts across all six

The cost of using models has fallen sharply while their ability to carry out longer software tasks has advanced. That improves the economics of these cycles, but it does not show that any given operation is already profitable (Stanford AI Index,METR). Productivity results in real work are not uniform either: a controlled study found cases where experienced developers were slower with the AI tools of early 2025 (METR).

The claim, stated carefully

The model was not impossible two or five years ago. Staged delivery, shared specialists and outcome-based contracts already existed. What may be changing is the frontier of viability: how many demands can sustain, with acceptable quality and price, the whole cycle of learning, execution, evaluation and decision.

Software Delivery as a Service organizes that new capacity as a recurring consumption relationship. Stages, gates and pools are mechanisms to make it concrete, not the original cause of the change.

Read the full argument →

A proposed model

Buy the next useful step of software, not the whole project.

A clear need still tends to start with a large, uncertain commitment. What if the first thing you bought were the answers: what to build, how it would work and what it would cost? AI may be what makes that worth offering.

Follow one requestUnderstand the model
Try the simulator

First, understand what we are proposing

Follow three requests across one board: what is bought at each step, when the buyer can stop, and how people and AI agents share the work.

About five minutes. The values are fictional and only illustrate the mechanics.

Open the simulator

One request, step by step

A barbershop wants customers to book appointments online. It has not decided every rule, and it has not bought a build.

  1. Discovery.It buys a bounded first step: the rules, a prototype and an examination of what the existing calendar allows.
  2. An informed offer.What was learned becomes a concrete offer, with options and a price that can be compared.
  3. Your choice.Build it, build only part, ask for an adjustment, wait, or stop. Stopping after a useful discovery is a fulfilled purchase, not a failure.

Why this was out of reach

Before anything is built, someone has to turn a wish into rules, try the experience and prepare an offer. That work costs real effort around every commitment.

When it is out of proportion to a small demand, the buyer is asked for a large first purchase, or the provider recovers the cost later through the build.

The bet on AI

AI can take part in the whole cycle: interpreting a request, prototyping, investigating, producing, evaluating and preparing the next decision.

If that lowers the complete effort at adequate quality, more demands become worth serving in small, informed steps. Faster code generation alone would not be enough.

What changes for the buyer

Each step delivers something usable and the information needed for the next decision.

You can authorize each step yourself or delegate the choices. Behind the service, the provider organizes recurring capacity of people and AI, so you never have to coordinate each executor.

Explore the model

What would have to be true

This is a proposal we are examining, and it can be wrong. Three things must hold at once: the service has to work, its economics have to repeat, and buyers have to choose it.

Each is a separate question, and each stays open.