What makes a software contract verifiable rather than just detailed?

Acceptance has to be defined as something you can execute rather than something you attend. A runnable suite that you can run yourself, on your own infrastructure, and that fails when a stated guarantee breaks, replaces a sign-off meeting where two parties compare impressions of a demo.

Why is "delivered to the agreed specification" a weak acceptance clause?

Because it delays the disagreement rather than resolving it, and the disagreement then happens at the end when the money is already spent. Both sides read the specification differently and both readings are usually defensible, so the clause protects whoever has more patience for a dispute.

When is a fixed price appropriate for software work?

Only for work where the uncertainty has already been removed, usually because a paid discovery phase produced a specification detailed enough to check. A fixed price on unscoped work is a bet, and the supplier prices the bet into the number, so you pay for the risk whether or not it happens.

What should be on the exit list in a build contract?

Source repositories with full history, infrastructure definitions, every credential and account, the deployment runbook, the checks that prove the guarantees, and a record of the decisions that shaped the design. Agree the list on the first day, because the day you need it is the day goodwill between the parties is at its lowest.

How do you write acceptance criteria for work that cannot be fully specified?

Split the contract: pay for a discovery or prototype phase with a deliverable of a specification and a check suite, then contract the build against that. Trying to fix the price of something nobody can describe yet produces either an inflated number or an argument in month four.

Does asking a supplier for a checkable definition of done create an adversarial relationship?

It usually does the opposite, because an open-ended opinion at the end is a risk the supplier carries too. A written, runnable definition of finished protects them from a client who keeps discovering new expectations, which is the reason a good supplier tends to welcome it.

What clause do buyers most often forget?

What happens when something breaks after the final payment: how long the warranty runs, what response is expected, and what counts as fixed rather than acknowledged. Contracts are usually detailed through delivery and say nothing at all afterwards, which is exactly where the expensive surprises happen.

How should a contract handle AI-assisted delivery specifically?

Ask what evidence arrives with the code rather than whether AI was used, because the second question tells you nothing useful. When a supplier can produce a large volume of plausible working code quickly, the amount of code no longer proves anything, so the contract should require the checks, the specification they were written from, and the ability to run them yourself.

Should the contract name specific people on the supplier side?

Naming individuals as the quality mechanism tends to fail, because people leave and the obligation leaves with them. It is stronger to make the supplier organisation accountable for the outcome, and to require that any knowledge one person holds is written into the handover material.

How do you avoid a contract that leaves you unable to change suppliers?

Require that everything runs on infrastructure you control or can take over, that no proprietary component is essential without a stated way to replace it, and that the handover material would let a competent third party continue. Test the claim by asking what a new team would need on their first morning.

What is a reasonable payment structure for a build?

Tie payments to verifiable milestones rather than to elapsed time, where each milestone has a check that can pass or fail without anyone needing to judge it. Time-based payment rewards duration, and demo-based payment rewards presentation, while evidence-based payment rewards the thing you actually wanted.

How to negotiate a software contract you can actually verify: Reveneau

We spend a fair amount of time reading contracts a client has already signed or is about to. The pattern is consistent enough to be predictable.

The document is careful about three things: who does the work, how long it takes, and when money is paid. Those are the parts a lawyer can draft without knowing anything about software. Then it reaches the question that actually decides whether the project ends well, and it becomes vague.

On what evidence do both parties agree the thing is finished?

The usual answer is "delivered in accordance with the agreed specification". That sentence looks like an answer but does not answer the question. Every build dispute we have looked at started there, with two parties reading the same specification differently, both of them sincerely, and no mechanism in the contract to settle it except who has more patience.

This got harder recently, and it is worth being direct about why. When a supplier can produce a large volume of plausible, working-looking code quickly, volume stops being evidence of anything. A demo that runs proves that a demo runs. The contract has to say what proof arrives alongside the code, or you have paid for a show.

Four clauses matter more than the hourly rates. In order.

1. Define done as something you can run

Acceptance should be a suite you can execute yourself, on infrastructure you control, that fails when a stated guarantee breaks.

Not a demo. Not a sign-off meeting. A demo shows only the parts of the software chosen by the person who wants you to approve it, and everyone in the meeting knows this, which is why demo-based acceptance produces such polite meetings and such unhappy clients by month seven.

The practical version looks like this. During scoping, both sides write down what the software must guarantee. A user can only see their own organisation's records. An invoice total equals the sum of its lines, in every currency, including refunds. A deletion removes the record from the primary store and from every derived copy. These become executable checks, written from the specification rather than from the implementation, and the contract names them as the acceptance condition.

The order is the most important part. Checks written after the code, by reading the code, assert that the software does what it does. They pass automatically, because of how they were written, and they prove nothing. Written from the specification first, they can genuinely fail, and a check that can fail is the only kind worth putting in a contract. The method is in writing specs an agent can verify and how to write your first eval suite.

One caution, because it is the failure we see most. Ask to run the suite yourself, in your own environment, before final payment. A passing result on the supplier's machine is a claim, and there are many examples of check suites that pass every time for reasons unrelated to the software being correct.

2. Price uncertainty honestly, or remove it first

Buyers ask for a fixed price because it feels like moving the risk to the supplier. Often the supplier just charges more for that risk.

A supplier quoting a fixed number for work nobody has scoped is making a bet. They will price the bet, because they would be foolish not to, and the extra amount they add is invisible to you. If the work turns out to be simple, you paid for a risk that never happened. If it turns out to be complicated, you get an argument about change requests in month four, which costs both parties more than the extra amount would have.

The honest structure splits the problem. Pay for a discovery phase with a real deliverable: a specification detailed enough that both sides can check it, the check suite derived from it, and an estimate with its assumptions written down. Then contract the build against that. Now the fixed price is attached to something that has actually been examined, and the number means something.

This is also the point where you learn the most about the supplier, for a low price and with no long commitment. How they handle the ambiguous parts of discovery tells you more than any reference call. More on the trade-offs between structures is in pricing and engagement models, and the scoping side is in how to scope the first project.

3. Write the exit list on the first day

Every contract should contain a named list of what you receive when the engagement ends, whether it ends well or badly.

"Reasonable assistance with transition" is not that list. It is an invitation to negotiate at the worst possible moment, when one party has been paid and the other is unhappy.

The list should name, specifically:

Source repositories, with full commit history, in accounts you own.
Infrastructure defined as code, not as a configuration somebody did by hand in a console.
Every credential, account, domain, and third-party service, transferred to your ownership.
A deployment runbook that a competent engineer could follow without asking anyone.
The check suite and the specification it was written from.
A record of the decisions that shaped the design, including the ones that were rejected.

That last item is the one people skip and later want most. Code shows what a system does. It never shows what was considered and ruled out, which is exactly what the next team needs before they change anything. We have written about what the team taking over goes through in how to take over a codebase you did not write.

Test the clause with one question: what would a new team need on their first morning to keep this running without calling anyone? If the honest answer includes a phone call, the exit list is incomplete. The wider version of this test is in avoiding vendor lock-in.

4. Say what happens in month seven

Most contracts are detailed through delivery and silent afterwards. Software does not work that way. The interesting failures arrive after launch, under real load, with real data, at a volume nobody simulated.

So the contract needs four things about that period. How long the warranty runs. What response time is expected. What counts as covered, which is the contested one, because "a defect against the agreed specification" and "something we did not think of" are different categories and the second is where most incidents come from. And what fixed means, since acknowledged, worked around, and actually repaired are three different states that get reported with the same word.

Related to this, be careful about contracts that make an individual the quality mechanism. Naming a person as the accountable reviewer sounds reassuring and it fails the ordinary way: people move on, and the obligation leaves with them. Accountability that lasts is organisational, attached to the outcome and to the material that stays behind.

What to ask a supplier before signing

Five questions. The answers tell you more than the proposal document.

What arrives with the code as proof? You want checks written from the specification, and the ability to run them yourself. A supplier who has thought about this answers immediately and specifically.

What would we need if we took this in-house tomorrow? A good answer is a list. A bad answer is reassurance.

What in this scope are you least sure about? Everyone has a least-certain area. A supplier who names it is telling you where the estimate is uncertain, which is useful and honest. A supplier who claims uniform confidence across an unbuilt system is either not paying attention or trying to control what you think.

How do you decide something is finished? Listen for whether the answer is a process or an artefact. Processes change over time without notice, artefacts can be inspected.

What happens when it breaks and it is ambiguous whose fault it is? The response to this question predicts the relationship better than the rate.

More of these, with the reasoning behind each, are in questions to ask a software development partner.

The part buyers get wrong about tone

There is a worry that asking for verifiable acceptance signals distrust and starts the relationship badly. In our experience the opposite happens, and the reason is structural rather than sentimental.

An unbounded definition of done is a risk the supplier carries as well. Without a written definition of finished, a project can take on an unlimited number of new expectations that arrive late, and the supplier either pays the cost or fights about it. A checkable definition protects them from that. Suppliers who resist it are usually resisting the clarity rather than the paperwork, and that is a useful thing to learn in week one rather than in month six.

Thanks to the operators who let us read the contracts that went wrong, including the ones where their own side made the mistake. The pattern was never a missing clause about payment. It was a project that finished with two reasonable people disagreeing about whether it had finished at all.

A contract cannot make a supplier good. It can make sure everyone finds out early.

Related guide: Total cost of ownership.

How to negotiate a software contract you can actually verify