Every software contract answers one question: when something turns out to be harder than expected, who pays? There are three common answers, and each puts the risk in a different place. Picking the wrong one for the situation is a quiet way to start a project badly.
This post walks through all three, says where the risk sits, and explains which one we use when.
The thing every model is managing
Software estimates are uncertain. Not because anyone is careless, but because a project is partly discovery. You do not fully know what the system needs to do until people have used a version of it, and you do not fully know how hard a piece is until someone has built it. The uncertainty shrinks as the project goes, but it never reaches zero.
A contract model is a decision about who absorbs that uncertainty: the client, the firm, or both in some arrangement. There is no model that makes it disappear. There are only models that put it somewhere sensible and models that hide it until it explodes.
Fixed price, fixed scope
The number is locked. The feature list is locked. The firm delivers the list for the number.
Where the risk sits: with the firm, on paper. If a feature takes twice as long as estimated, the firm eats it.
What actually happens: the firm knows this, so the price includes a margin for the unknowns. Sometimes a large one. Then, because the scope is locked, every change becomes a change order, and every change order is a negotiation. Projects under this model tend to produce one of two things: a system that matches the original spec but not what the business needed by the time it shipped, or a change-order pile that quietly puts the risk back on the client with paperwork attached.
When we use it: when scope is genuinely nailed down. A well-bounded integration, a defined module added to a system we already know, a second release where the first one settled most of the questions. In those cases the uncertainty is small enough that locking both sides is fair to everyone. We will not use it for a first release of a system nobody has designed yet, because we would either be guessing or padding, and neither is honest.
Time and materials
The firm bills for hours worked. The scope is whatever it turns out to be. The client pays for what it took.
Where the risk sits: with the client, entirely. If it takes longer, it costs more. There is no ceiling unless one is written in.
What actually happens: for the right kind of work, this is the fairest and simplest model there is. For the wrong kind, it is how a project becomes a monthly invoice with no end date. The difference is whether there is a natural boundary on the work.
When we use it: for ongoing and advisory work, and always with a monthly cap. Fractional CTO time, maintenance and support hours, a standing AI and automation team. Work that is continuous by nature, where “done” is not the point and the cap keeps the spend predictable. We do not use uncapped hourly for building a system. If someone proposes it to you for a build, ask what happens when the estimate is wrong, and listen carefully to the answer.
Fixed budget, controlled scope
The budget is fixed. The quality is fixed. The scope flexes inside the budget, and the client decides the trade-offs.
Where the risk sits: shared, and visible. The firm commits to the number and to the quality. The client commits to making scope decisions when the project learns something. Neither side gets to pretend the uncertainty is not there.
What actually happens: the project starts with a roadmap and a first release defined in design. As the build goes, things come up. A workflow is more complicated than anyone knew. A rule the accounting team never mentioned turns out to matter. A feature everyone wanted turns out to be something nobody uses in testing. Each time, the conversation is the same: here is what it costs, here is what could move to make room, which do you want? The number does not change. What ships inside it does, and the client holds the pen.
When we use it: by default, for almost every build. It is the model that matches how software projects actually behave. It rewards a strong first release, because the way to get more inside a fixed budget is to be disciplined about what goes first. And it keeps the client in control of the one thing that is theirs to control: what matters most.
The condition is that the client has to show up. A fixed budget with controlled scope needs a decision-maker who will answer the trade-off questions in days, not weeks. If nobody on your side can do that, the model does not work, and we will say so before we propose it.
A hypothetical, to make it concrete
Imagine a distributor that needs an order-management system to replace a spreadsheet and an aging desktop tool. Design produces a first release with four workflows and a fixed budget.
In week six, the team discovers that the returns process, which everyone described as “simple,” has eleven variations depending on the vendor, and three of them involve credits that flow into accounting differently.
Under fixed price and fixed scope, that is a change order, a week of negotiation, and either more money or a returns module that only handles the easy cases. Under uncapped hourly, it is two more weeks on the invoice and nobody asked. Under fixed budget and controlled scope, it is a fifteen-minute conversation: the full returns logic costs roughly this much; the vendor-scorecard screen everyone liked but nobody needs in release one costs about the same; do you want to swap them, or handle the three hard cases manually until release two? The client decides. The budget holds.
That is the whole difference. Same surprise, three very different projects.
Why we recommend instead of offering a menu
Some firms present all three models and let the client choose. We do not, and the reason is not control. It is that the right model depends on how well the scope is known, and the client cannot judge that before the work has been looked at. Neither can we, which is why the recommendation comes after the Deep Dive, not on the first call.
If the scope is tight, we will recommend fixed price and say why. If the work is ongoing, time and materials with a cap. If it is a build, which it usually is, fixed budget with controlled scope. And if the honest answer is “we cannot know the scope yet,” the recommendation is a VDP Sprint or a System Evaluation first, fixed fee, so the next proposal is built on something real.
Whatever the model, the paperwork is the same: a standard MSA and a short SOW. Fixed fees in milestone installments with part up front. Retainers monthly in advance. Invoices due in ten days. You own everything once it is paid for.
What to ask any firm
Whichever model a firm proposes, ask three questions. What happens when something takes longer than estimated? Who decides what gets cut or added, and how fast? What is the ceiling, and what is it made of? A firm that has thought about risk will answer in a sentence each. One that has not will talk about their process.
If you want to see how the answer sounds from us, start with a Discovery Call. We will not propose a model on it, but we will tell you which way we are leaning and what it would take to be sure. How the number itself gets set is in How we set a budget for a software project.