Every software development contract I’ve seen comes in one of two forms. Either you pay a fixed price for a product described in advance, or you pay for the developer’s time and get billed as the work goes along. Who carries the risk when the work doesn’t go according to plan? It’s an important question to ask because it almost never does.
I’m a programmer, and I’ve run a software firm since 2015, so I’ve sat on the developer’s side of both kinds of contract. I’m not going to argue that one of them is always right. I’m going to explain what each one does with the risk, and then tell you how we handle it. You can decide for yourself if our approach seems like the right one.
The two contracts
Under a fixed-price contract, you pay an agreed price for software described in a statement of work (or scope of work; both are abbreviated SOW) that’s incorporated into the contract. You pay a portion up front and the rest in progress payments tied to milestones, phases, or deliverables. If it becomes clear during development that the scope needs to change in some material way, both sides agree to a change order. The price may change with it. But that’s for changes to the scope itself, meaning the product delivered will be substantially different from what the SOW describes.
Under a time-and-materials contract, you pay for the developer’s time, typically by the hour, at a rate set in the developer’s professional services agreement (PSA). The developer gives you an estimate of the hours and the cost based on the specifications, but an estimate is an estimate: the final figure can come in a little above or below it, or a lot. In its simplest form the developer invoices you monthly on standard terms such as net 30, though billing can be tied to milestones here too.
Under both types of contract, you typically pay for the cloud resources used in development and production, either directly in your own account or by reimbursing the developer.
Time and materials: you carry the price risk
Under time and materials, your risk is that the estimate is too low and you’ll pay substantially more than you planned to get the product delivered. The most common reason (I would hope) is simply that the developer underestimated how long something would take. The road from SOW to delivered product is rarely a straight line. A third-party library doesn’t do what its documentation says it does, or turns out to have a limitation that was known to everyone except the developer preparing the estimate. A change you ask for mid-project adds hours beyond what was estimated. And you can’t rule out two less innocent explanations: that the developer lowballed the estimate to win your business, or that the estimate was fine and the developer isn’t in a hurry to call it done, because an hour worked is an hour billed.
In fairness to time and materials, it has two advantages a fixed price can’t offer. You pay only for the work actually done, with no risk premium built in (more on that in a moment), and you can stop at any point. That makes it the right contract for work whose scope can’t be known in advance: a backlog of small enhancements, an integration with a system nobody has documentation for, or a rescue where the first job is finding out what’s there.
Government buyers will recognize all of this. As I understand the federal acquisition rules, time and materials is the contract type of last resort, allowed only when the work can’t be estimated with reasonable confidence, and it requires a ceiling price. State and local procurement tends to follow the same instinct.
Fixed price: you carry the scope risk
Under a fixed price, the price risk moves to the developer. Since you aren’t paying by the hour, there’s no incentive to pad the time; the developer’s incentive is to deliver as quickly as reasonably possible, collect the final payment, and move on to the next project. And if the developer underestimated the work, that’s the developer’s cost to bear. We’ve been on the wrong side of that ourselves. We’ve quoted a price, found the work was far bigger than we’d figured, and finished the job for the price we agreed to. That’s what the contract means.
Two things come with that protection, and you should be aware of both. First, a developer who takes on the price risk prices it in. A fixed price is an estimate plus a margin for the things that go wrong, so on a project that happens to go smoothly you’ll have paid a little more than you would have on time and materials. That’s the premium for not carrying the risk yourself, and I think it’s usually worth paying, assuming it’s priced reasonably for the uncertainty. Second, the same incentive that gets the product delivered quickly can also get it delivered to the letter of the SOW and not one line further. Whatever the SOW doesn’t say, you may not get.
Which brings me to the risk you still carry under a fixed price: the scope itself. Writing a software specification is hard. If the SOW doesn’t describe the product you actually need, you’re paying the wrong price, and it can be wrong in either direction. If the SOW asks for more than you need, the project takes longer and costs more than it should have, even though it costs no more than the contract says. If it asks for less, you’ll either live with software that does only part of what you wanted or pay for change orders to cover what was left out, at a point in the project where you have very little bargaining power on the price. And if the SOW describes the wrong product altogether, the fixed price just means you’ll find out on budget.
In other words, a fixed price transfers the risk of estimating the work. It does nothing about the risk of describing the work. That one stays with you.
Caps and hybrids
Buyers who understand this often ask for a middle path: time and materials with a not-to-exceed cap. I’m not against caps, but be clear about what one does. A cap doesn’t transfer the price risk to the developer; it gives you the right to stop paying. If the estimate was wrong, you reach the cap with an unfinished product and a decision to make, which is exactly the situation the cap was supposed to prevent. The other common hybrid is a fixed price per phase, with each phase priced after the one before it is done. That’s a reasonable way to buy a large project, and it’s close to how we work.
How we handle it
No contract makes the scope risk disappear. What you can do is shrink it before you sign a fixed price, by doing the discovery first, as its own piece of work, and writing the specification from what it finds.
So that’s how we do it. The first step is a short fit call to find out whether we’re the right firm for what you need. The second is a fixed-fee assessment: we interview the people who actually run the process, inspect whatever system or spreadsheets you’re running it on now, and write a report with the requirements and a recommendation. The requirements are written down and you sign off on them before any build begins, and that document is the SOW. Only then do we quote a fixed price for the build. The build itself runs under a formal change-request process, and user acceptance testing by your own staff is the acceptance gate, so “done” is something you decide, not us. If the assessment finds that you’d be better served by an off-the-shelf product, or that you don’t need us at all, the report says so, and it’s yours either way. If, in the end, you choose a different vendor, the report will give them most of what they need to get started quickly.
If you want a sense of what the build is likely to cost before you commit to any of that, I published our ballpark ranges for Quickbase, Caspio, and custom builds recently. And if you’d like to talk through a project you have in mind, schedule a fit call.
