Fixed price or time and materials? Price the uncertainty, not the project.

Three quotes, three bets

You send the same brief to three development shops. One comes back with a fixed price. One sends an hourly rate and an estimate range. The third asks for a call because they have questions before they can quote anything.

It's tempting to compare the numbers. But these aren't three prices for the same thing. They're three different bets about something nobody knows yet: how much the project will change once real people start using it.

The pricing model is really a decision about who carries the unknowns. With a fixed price, the builder carries them and charges you for that. With time and materials, you carry them and keep the flexibility. Neither is cheaper in general. Each is cheaper for a certain kind of work.

The shop that asked for a call isn't necessarily being difficult, either. Often it's the one that noticed the brief describes a goal rather than a finished design, and wants to know how much of it is still open before putting a number on it. That's a useful sign, not a red flag.

Here's the menu as we see it, what each option buys you, and what it costs.

Option one: fixed price

What you're buying: certainty about cost for a defined scope. You know the number before you start, and your finance team will like that.

What it costs you: the builder has to price in the risk of being wrong. If they're sensible, the quote includes a margin for surprises. If they're not, they'll lose money and try to recover it later.

It also costs flexibility. Anything outside the original scope becomes a change request, with its own price and its own negotiation. That's fine when changes are rare. On a project where you'll learn a lot from the first users, it can turn every good idea into a contract discussion, and it creates a quiet incentive for the builder to deliver exactly what was written, even when everyone can see it's not quite right.

When it fits: the work is well understood and unlikely to change. A defined integration between two systems with clear specifications. A rebuild of something that already exists and works. A small, bounded piece with a clear finish line.

Option two: time and materials

What you're buying: flexibility. You pay for the time the team spends, and you can change direction as you learn, without renegotiating.

What it costs you: budget certainty. Estimates are estimates. And it asks something of you: someone on your side has to steer, weekly, deciding what matters most and what can wait. Without that, time and materials can drift.

It also depends heavily on trust. You need to see what the time is being spent on and whether it's turning into working software.

When it fits: the work involves real discovery. A new product where you don't yet know which features people will use. Software for a process that's never been written down. Anything with AI in it, where you'll need to test what actually works with your data before committing to a design.

How to make it safer: set a budget cap for a period, ask for a short written update each week, and insist on seeing working software regularly, not just reports.

Option three: a fixed start, then capped phases

For most custom software we see, neither pure option is right. The work is partly known and partly not, and the honest answer is to price those parts differently.

A short fixed-price discovery. A few weeks to understand the work, sit with the people who'll use the software, map the exceptions, and produce a clear plan and an estimate for the first useful version. You know what this costs. At the end, you have something useful even if you don't continue. We wrote about what to put in it in writing the brief before you pick the builder.

Then capped phases. Each phase has a fixed budget and a goal, but the exact scope inside it is flexible. You agree on the priorities at the start, the team works through them, and at the end there's working software you can see and use. Then you decide whether to start the next phase, change direction or stop.

This gives you most of the cost control of a fixed price, and most of the flexibility of time and materials. It also gives both sides regular, natural points to step back and ask whether the work is going well. And if the relationship isn't working, you find out after one phase, with working software in hand, rather than at the end of a long contract with nothing to show.

How to choose

Four questions usually make the choice clear:

• How well can you describe the work today? If you can write down every screen and rule, and you're confident they won't change, fixed price can work. If you're describing a problem rather than a solution, it won't.
• How much will you learn after the first users try it? The more you expect to learn, the more expensive a fixed scope becomes.
• Who on your side can steer? Time and materials, or capped phases, need someone who can make decisions every week.
• What happens if it runs over? If the budget truly can't move, you need caps and phases, not a hopeful estimate.

Whatever you sign, write these in

The pricing model matters less than a handful of things that belong in every software contract:

• What "done" means for each piece of work, in terms someone can check.
• How changes are handled: who can ask for one, how it's estimated, who approves it.
• Regular demos of working software, not just status updates.
• Handover: code, documentation, access and accounts in your name. Our note on what a useful software handover should include goes into detail.
• How either side can stop, and what you get if they do.
• What happens after launch: support, fixes and who owns them, which we covered in what ongoing partnership should mean in a software contract.

We build web applications that fit how a business actually works, usually starting with a short discovery and moving in phases you can see. If you're comparing quotes and they don't line up, send them over and we'll talk them through.

Related work: PatientIQ.