Pay on delivery software development: how it works

A company that has paid for software once and got nothing usable will, on the next attempt, ask a version of this question: can I pay when it works instead of paying while you try? It is an entirely reasonable question and the honest answer is yes, with conditions that most people asking have not thought about yet.

Pay on delivery is not one arrangement. It is a family of them, and the differences between them decide whether you end up with less risk or just a different risk wearing better clothes.

What the three common versions actually mean

Milestone payment is the common one and the weakest form of protection, because the thing being paid for is whatever the contract said, not whatever you needed. If the milestone reads "user login screen delivered", you will get a login screen, on time, and it may sit in front of an application nobody can use.

Phase gate is the version worth arguing for, and it is the version public sector procurement has already standardised on.

The phase-gate model, borrowed from people who publish theirs

The UK Government Digital Service publishes its delivery model openly, which makes it a useful reference precisely because nobody is selling it to you. The Service Manual defines five phases: discovery, alpha, beta, live and retirement.

The durations are stated. Discovery is where you "understand the problem that needs to be solved", and "around 4 to 8 weeks is typical". Alpha is where "you try out different solutions to the problems you learnt about during discovery", and "alphas tend to last between 6 and 8 weeks".

Two details in that guidance matter more than the durations. The first is what alpha produces: prototypes "just complex enough to let you test different ideas, not production quality code", with the expectation that you "discard code and tested ideas by phase end". The second is the exit condition. To move to beta a team must be able to show it can "create something that meets users' needs and is cost-effective" and has "the budget and people necessary to deliver".

And then the sentence that makes the whole model honest: "It's okay to decide at the end of your discovery that you do not think it's worth running an alpha." Stopping is a legitimate outcome, not a failure.

Why that sentence is the whole point

A pay-on-delivery arrangement that has no defined way to stop is not risk transfer. It is a payment schedule. The value of the phase gate is that at a known moment, with a known amount spent, both sides look at what has been learned and either continue or do not, and neither party is embarrassed by the second option.

This is why we keep saying that the expensive failures are scoping failures rather than engineering ones, which we set out at length in how to scope a software project before anyone writes code and in why software projects take so long.

What it costs you, because it does

Three costs, all of them real and none of them usually mentioned by whoever is offering the arrangement.

• Price. A supplier carrying delivery risk prices for it. Expect the total to be higher than a time-and-materials equivalent, because you are buying insurance and insurance has a premium.
• Flexibility. Payment tied to a defined deliverable makes changing the deliverable a contractual event. Mid-project learning, the thing that actually improves software, becomes a renegotiation.
• Scope conservatism. A team paid on acceptance will propose what it is confident it can get accepted. That is rational and it is also how you end up with the safe version of your product.

The third one is the cost nobody predicts and the one that hurts longest. If you want an ambitious build, an arrangement that punishes the supplier for uncertainty is working against you.

How to structure it if you want it anyway

• Pay for discovery outright and separately, at a small fixed price. It is the phase with the most uncertainty and the least code, and demanding it for free selects for suppliers who skip it.
• Gate at the end of discovery and again at the end of alpha, with a written continue-or-stop decision each time.
• Define acceptance as something a named person can test in an afternoon, not as a document.
• Agree what happens to the code if you stop. This is a two-line clause and its absence has ended otherwise recoverable projects.
• Keep the first phase short enough that stopping is genuinely affordable. If phase one costs more than you can walk away from, the gate is decorative.

The honest limit

Pay on delivery works well when the outcome is definable and the supplier controls most of what it depends on. It works badly when delivery depends on your team providing data, decisions or access, which is most integration work, because now the supplier is carrying a risk that you are creating and the price reflects that.

It also does nothing about the failure mode we see most often, which is not a supplier who cannot build but a buyer who has not decided what should exist. No payment structure fixes that. Deciding does, and it is cheaper than any contract clause.

If you are approaching this from the supplier side and trying to price the risk you would be taking on, the commercial reasoning is set out well in BDG Labs' note on how to price a B2B service without guessing at the number.

And if what you are really trying to work out is whether a given supplier can be trusted at all, the payment structure is a late and weak signal. The earlier ones are in how to choose a software development company.