Paying for outputs, not hours: a framework for output based software contracts

Background

When you buy software work by the hour, you pay for effort. If the effort produces working software, good. If it produces a half finished module, a missed deadline or a rewrite, you still pay for the hours. The supplier carries little delivery risk. You carry most of it.

Fixed price contracts were meant to fix this, but they have their own problems. Suppliers pad the price to cover unknowns. Scope disputes start the moment the first change request arrives. And a fixed price with a large advance still leaves you exposed if the work goes badly.

Output based contracts try a different route. You pay when a defined output is delivered and you accept it. Done well, this aligns both sides on the thing you actually want, which is working software. Done badly, it produces endless arguments about whether something is "done".

Approach

This paper is based on analysis of public documents and the practices we use in delivery. On the legal side, we considered how the Indian Contract Act, 1872 treats performance, acceptance and payment terms in general, and how the Micro, Small and Medium Enterprises Development Act, 2006 treats delayed payments to registered micro and small suppliers, since both shape how payment triggers should be drafted in India.

On the delivery side, we drew on the rules we use under our Output Oriented Engagement (O2E) model, where work is arranged in fixed capacity blocks and paid after review and acceptance, with a signed technical specification deciding what acceptance means. No client data, contracts or outcomes are used.

Findings

1. Acceptance is the whole contract

In an output based contract, the acceptance clause carries the weight that the rate card carries in a time based contract. If acceptance depends on a buyer feeling satisfied, the supplier cannot price the risk and the buyer has no stable test. Acceptance has to be tied to written criteria that both sides could check independently and reach the same answer.

2. Specifications are usually written too late or too loosely

Many projects go straight from a sales conversation to a statement of work that lists features in a sentence each. "User management module" is not a specification. It hides a dozen decisions about roles, permissions, password rules, audit logs and integration with existing directories. Each hidden decision becomes a dispute at acceptance.

3. Change is normal and has to be priced

Business needs move during any project longer than a few weeks. A contract that treats change as an exception will either be ignored or will block sensible adjustments. Contracts that work treat change as a routine event with its own small process: describe it, estimate it, agree it, update the specification.

4. Payment triggers need deadlines on both sides

If the buyer can delay review indefinitely, the supplier is effectively financing the project. If the supplier can submit half finished work for review, the buyer wastes time. A review window, with deemed acceptance or a written list of failures by its end, protects both.

5. Quality work gets cut when it is not part of the output

Code review, testing, documentation and project management are easy to drop when a supplier is paid per output. The contract has to say that these are a required part of every output.

6. Not all work fits

Open ended research, exploratory prototypes and work where the problem itself is unclear cannot be specified upfront. Forcing them into an output based contract produces either a vague specification or an inflated price. Those are better run on time based terms, or on an embedded model, until the problem is clear enough to specify.

A framework

We call this the Acceptance Chain. Each link produces a document. Each document is signed before the next link starts. Payment is triggered only by the last link.

1. Business discovery. A short written record of the problem, the people affected, the current process and the result you want. For example: "Sales orders arrive by WhatsApp and email and are typed into Tally by two people. We want orders captured once and pushed to Tally with stock checked."
2. Business requirements. What the system must do, in business language, with priorities. Each requirement has an owner on the buyer side.
3. Signed technical specification. Screens, data, integrations, rules, error handling, performance expectations and security controls, in enough detail that a different competent team could build from it. This is the document that decides acceptance.
4. Acceptance tests. For each item in the specification, a test or demonstration with an expected result. Write these before the build starts. If a requirement cannot be turned into a test, it is not ready.
5. Review window and payment trigger. The supplier submits an output with evidence that tests pass. The buyer has a fixed number of working days to accept or return a written list of failures against the tests. Payment follows acceptance.
6. Change control. Any change to the specification is written as a change note with its effect on capacity and timeline, agreed by both sides, and added to the specification before work on it starts.

Criteria to check a draft contract

• Can you point to the clause that defines acceptance, and does it refer to a signed document?
• Does every output include review, testing and documentation as standard?
• Is there a review window with a defined end?
• Is there a written change process, and does it update the specification?
• Is there any advance? If so, what risk is the advance covering, and could a smaller first output cover it instead?
• Is ownership of code and intellectual property clear on acceptance and payment?

Recommendations

1. Spend proportionately on the specification. For a project of a few hundred hours, a week of specification work is normal and cheap compared with a dispute.
2. Break the work into small outputs. Outputs of a few weeks each keep review manageable and limit the cost of any one failure.
3. Write acceptance tests with the people who will use the system. An accountant will spot a missing GST field faster than a project manager will.
4. Keep a single specification of record. Change notes update it. Old versions are kept.
5. Use time based terms for the unclear parts. A short paid discovery, or an embedded team, can turn an unclear problem into a specification. Then switch to output based terms.
6. Have a lawyer review the template once. After that, the commercial terms rarely change and the specification does the work.

Limitations

This paper reflects the practices of one delivery model and the legal context of India. Contract law and payment rules differ by country, and nothing here is legal advice. The framework works best for software with clear functional requirements, such as business applications, integrations and data pipelines. It is a weaker fit for AI systems whose quality is statistical, where acceptance has to be defined as a score on an agreed evaluation set. Finally, output based contracts ask more of the buyer in the early weeks, because someone has to read and sign the specification. Buyers who cannot spare that time will find the model harder to use.

Sources

• Indian Contract Act, 1872
• Micro, Small and Medium Enterprises Development Act, 2006
• Digital Personal Data Protection Act, 2023 (India)