# Software Delivery as a Service > A proposed operational, economic and commercial model for consuming software delivery, and the role AI could play in making it viable. Software Delivery as a Service is a proposed model, not a report of an operation or of measured results. Authors: Renan Deves and Marcelo Scheidt, Independent Researchers. Content is licensed under CC BY 4.0. ## Paper - [Paper](https://softwaredeliveryasaservice.com/paper/): Software Delivery as a Service, by Renan Deves and Marcelo Scheidt. Published as a preprint on Zenodo on 22 September 2026 under CC BY 4.0. The citable record is https://doi.org/10.5281/zenodo.22904797 ## Articles - [What It Means to Consume Software Delivery](https://softwaredeliveryasaservice.com/articles/consuming-software-delivery-as-a-service/): What is being purchased. - [Buying Discovery Before Building](https://softwaredeliveryasaservice.com/articles/buying-discovery-before-building/): Useful information as the first delivery. - [From Learning to the Next Offer](https://softwaredeliveryasaservice.com/articles/from-learning-to-the-next-offer/): Estimates, offers, and commitments. - [The Right Not to Buy the Next Step](https://softwaredeliveryasaservice.com/articles/choosing-what-happens-next/): Usable parts, deferral, and closure. - [Autonomy Begins with Authority](https://softwaredeliveryasaservice.com/articles/delegating-delivery-decisions/): Delegated decisions and their limits. - [Production Must Be Ready for the Next Demand](https://softwaredeliveryasaservice.com/articles/organizing-recurring-delivery-capacity/): Capacity, context, and evaluation. - [A Demand That Retains Its Identity](https://softwaredeliveryasaservice.com/articles/delivery-units-and-stage-contracts/): Delivery Units and Stage Contracts. - [When AI Changes Delivery Economics](https://softwaredeliveryasaservice.com/articles/when-ai-changes-delivery-economics/): Full cost and demands that become viable to serve. - [Purchasing an Advance You Can Recognize](https://softwaredeliveryasaservice.com/articles/procuring-useful-advances/): Scope, comparison, and responsibility. - [What Would Make This Model Scale?](https://softwaredeliveryasaservice.com/articles/what-would-make-this-model-scale/): Repetition, sustainability, and adoption. ## The Model - [The model](https://softwaredeliveryasaservice.com/model/): Software Delivery as a Service in one continuous read, following a single demand from the first request to the decision to continue or stop. - [Economics](https://softwaredeliveryasaservice.com/model/economics/): The economic hypothesis behind Software Delivery as a Service, and how estimates, commitments, economic decisions, prices and unit economics express it. - [Commercial Gate](https://softwaredeliveryasaservice.com/model/economics/commercial-gate/): The economic decision to continue, revise, defer or stop a commitment, which can be taken directly or under delegated authority, and which is never the same as technical acceptance. - [From hours to outcomes](https://softwaredeliveryasaservice.com/model/economics/from-hours-to-outcomes/): How the object of consumption can shift from capacity towards bounded deliveries, what that requires, when capacity still makes sense, and what AI could change about it. - [Outcomes](https://softwaredeliveryasaservice.com/model/economics/outcomes/): What "outcome" means in the model, and why an accepted software delivery and a later business effect have to be kept explicitly apart. - [Pricing](https://softwaredeliveryasaservice.com/model/economics/pricing/): How price and charging relate to what is offered, the scope of the commitment and the allocation of responsibilities, and why price is not the same as cost, estimate or value. - [Progressive Commitment](https://softwaredeliveryasaservice.com/model/economics/progressive-commitment/): Expanding or revising what the parties have assumed as a demand becomes better defined, without turning a forecast into an obligation or a finding into permission to do more. - [Progressive Estimation](https://softwaredeliveryasaservice.com/model/economics/progressive-estimation/): Updating estimates of effort, time, cost and risk as context, artifacts and evidence change, and why an estimate is neither a price nor a commitment. - [Unit Economics](https://softwaredeliveryasaservice.com/model/economics/unit-economics/): How to relate revenue or attributed resources, consumption and results through an explicit unit of analysis and period, including the routes that end without construction. - [Software Delivery Engine](https://softwaredeliveryasaservice.com/model/engine/): The operational composition of coordination, execution, evaluation and continuity that carries out demands and keeps the capacity to provide the service. - [Escalation](https://softwaredeliveryasaservice.com/model/engine/escalation/): Routing a question to the competence or authority it requires when it exceeds the scope available, without turning every exception into a universal human approval. - [Evaluation](https://softwaredeliveryasaservice.com/model/engine/evaluation/): The activity of examining outputs and evidence against the relevant criteria, which supports, but is not the same as, the Quality Gate's decision to accept. - [Execution Policy](https://softwaredeliveryasaservice.com/model/engine/execution-policy/): The rules for eligibility, selection, autonomy and supervision of execution, stage by stage, and why human, hybrid and autonomous execution can be judged against the same result. - [Execution Pools](https://softwaredeliveryasaservice.com/model/engine/execution-pools/): Eligible resources shared across demands to organize recurring capacity, the conditions that make sharing worthwhile, and when dedicated resources make more sense. - [Execution Resources](https://softwaredeliveryasaservice.com/model/engine/execution-resources/): The people, agents and arrangements eligible to perform work, what makes one usable for a given stage, and the limits that remain when the composition of execution changes. - [Governance](https://softwaredeliveryasaservice.com/model/engine/governance/): The rules and responsibilities that establish who may decide, delegate, change conditions and answer for the effects of delivery, in proportion to the work. - [Mandates](https://softwaredeliveryasaservice.com/model/engine/mandates/): Delegated authority across buyer, provider and environment, its limits, and why being able to act is never the same as being authorized to act. - [Orchestration](https://softwaredeliveryasaservice.com/model/engine/orchestration/): The coordination of the flow that relates each demand's state, conditions, dependencies and commitments to the next permitted step, and the Orchestrator function that carries it out. - [Quality Gate](https://softwaredeliveryasaservice.com/model/engine/quality-gate/): The decision on technical or quality acceptance of an output, distinct from the evaluation that supports it, from the Commercial Gate, and from permission to change production. - [Retry](https://softwaredeliveryasaservice.com/model/engine/retry/): A bounded new attempt at execution, justified by the conditions and respecting the authorization, limits and effects of the previous attempt, and why diagnosis comes before repetition. - [Routing](https://softwaredeliveryasaservice.com/model/engine/routing/): How the Execution Policy is applied to authorized work, eligible resources and actual availability to produce an assignment that can be executed, or an honest finding that none is possible. - [Foundations](https://softwaredeliveryasaservice.com/model/foundations/): Why Software Delivery as a Service is proposed at all, from how software is delivered today to the change AI could bring and what it means for what is bought. - [From capacity to outcomes](https://softwaredeliveryasaservice.com/model/foundations/from-capacity-to-outcomes/): What is bought when capacity is bought, what changes when the delivery guides the commitment, and how buying the advance that allows a decision could become viable, without promising business results. - [Software delivery today](https://softwaredeliveryasaservice.com/model/foundations/software-delivery-today/): How a need becomes usable software, how much work that takes before, during and after implementation, and where a demand runs into the constraints of the operation. - [The abstraction problem](https://softwaredeliveryasaservice.com/model/foundations/the-abstraction-problem/): Why the buyer of software delivery still has to organize too much, how people, hours, tasks and projects represent different things, and what a representation of the demand would need to preserve. - [Why AI changes the model](https://softwaredeliveryasaservice.com/model/foundations/why-ai-changes-the-model/): The enabling hypothesis. AI could reduce the complete cost of turning an intention into an executable commitment and carrying it out, and technical capability is not the same as economic viability. - [Glossary](https://softwaredeliveryasaservice.com/model/glossary/): Working definitions of the terms used by Software Delivery as a Service, each linked to the page that explains it. - [Implications](https://softwaredeliveryasaservice.com/model/implications/): The possible organizational, operational and commercial consequences of Software Delivery as a Service, all conditional on viability and adoption. - [Organization](https://softwaredeliveryasaservice.com/model/implications/organization/): How a provider could organize recurring capacity that turns intentions into advances that can be bought, combining dedicated teams, shared pools and clear responsibilities, without a universal structure. - [Procurement](https://softwaredeliveryasaservice.com/model/implications/procurement/): What buyers could compare and authorize progressively: purchased discovery, offers to continue, partial choices and delegated decisions, compared by scope and responsibility rather than by headline price. - [Role of AI](https://softwaredeliveryasaservice.com/model/implications/role-of-ai/): AI's part across the whole delivery cycle, from assistance to autonomous conduct including delegated decisions, with variable autonomy and evaluation criteria that keep production apart from demonstration. - [Role of humans](https://softwaredeliveryasaservice.com/model/implications/role-of-humans/): Where people fit when delivery can be hybrid or autonomous within mandates: engineering, judgment, system design, production, evaluation and exceptions, without a universal path for professionals. - [Scaling](https://softwaredeliveryasaservice.com/model/implications/scaling/): What it would mean to serve more intentions and fulfil more advances without proportional growth in coordination, why bottlenecks move, and how to measure scale honestly. - [Software economics](https://softwaredeliveryasaservice.com/model/implications/software-economics/): The possible market effects of the model, as a conditional widening of viable demands, with alternative scenarios and the signals that would support or weaken each, and no inevitable prediction. - [Design principles](https://softwaredeliveryasaservice.com/model/principles/): The ten commitments that guide how Software Delivery as a Service turns the possibility enabled by AI into a service, each linked to the pages that put it into practice. - [Reference model](https://softwaredeliveryasaservice.com/model/reference/): How the parts of Software Delivery as a Service work together, shown on one fictional demand followed from first request to deployment. - [Reference architecture](https://softwaredeliveryasaservice.com/model/reference/architecture/): A logical architecture for the barbershop case, relating the consumption interface, the demand's records, coordination, execution, evaluation and authority, without prescribing a platform. - [Example Delivery Unit](https://softwaredeliveryasaservice.com/model/reference/example-delivery-unit/): The complete fictional case of DU-001, online booking for a barbershop, with its commitments, amounts, evidence and alternative endings. - [Intent to production](https://softwaredeliveryasaservice.com/model/reference/intent-to-production/): A barbershop's online booking followed from the first request, through a purchased discovery and an informed offer, to production, including where it could stop. - [Reference pipeline](https://softwaredeliveryasaservice.com/model/reference/pipeline/): The five transformations of the barbershop case, with their inputs, outputs, acceptance decisions, returns and authorizations, and why a stage is not a charge. - [State machine](https://softwaredeliveryasaservice.com/model/reference/state-machine/): One possible concrete state machine for the barbershop case, separating the unit's lifecycle, the situation of each stage, commitments and pending items. An illustration, not a norm of the model. - [Structures](https://softwaredeliveryasaservice.com/model/structures/): How Software Delivery as a Service represents a demand, the transformations it goes through, their conditions, and the information that supports decisions about it. - [Artifacts](https://softwaredeliveryasaservice.com/model/structures/artifacts/): The concrete products of delivery work, such as requirements, prototypes, code and tests, and why producing one is not the same as showing it is adequate. - [Delivery Stage](https://softwaredeliveryasaservice.com/model/structures/delivery-stage/): The unit of transformation that turns available inputs into outputs that can be evaluated, with an explicit purpose in the route of a demand. - [Delivery State](https://softwaredeliveryasaservice.com/model/structures/delivery-state/): The representation of a demand's current situation, relating progress, pending items, dependencies and the conditions for continuing, so that decisions can be made on it. - [Delivery Unit](https://softwaredeliveryasaservice.com/model/structures/delivery-unit/): The tracking unit that keeps a bounded demand recognizable while its interpretation changes, different executors work on it, and commitments are made about it. - [Evidence](https://softwaredeliveryasaservice.com/model/structures/evidence/): The information that supports an evaluation or decision about a demand, what makes it relevant and sufficient, and why its conclusions stay bounded. - [Stage Contract](https://softwaredeliveryasaservice.com/model/structures/stage-contract/): The specification of the conditions under which a transformation can be carried out and its output judged. It is an operational specification, not a legal document. ## Optional - [Full text of the site](https://softwaredeliveryasaservice.com/llms-full.txt): every page and article in one file - [Articles feed](https://softwaredeliveryasaservice.com/articles/rss.xml)