Fixed Price vs Time and Materials for Software Development: The Risk Owner Test

Most conversations about software pricing models start in the wrong place. A buyer asks for a fixed price because it feels safe. A vendor proposes time and materials because the scope is unclear. Both sides then argue about the model, when the real disagreement is about something else entirely: who carries the risk when the work turns out to be different from what anyone expected.

Every software project contains uncertainty. A pricing model does not remove it. It only decides who pays when the uncertainty turns into cost. Choose the model without looking at the risks underneath and you end up with a fixed price padded to cover unknowns, or an open-ended engagement with nobody accountable for efficiency.

This guide is for founders, CTOs and procurement leads commissioning custom software. It gives you a structured way to choose: the Risk Owner Test.

What each pricing model actually does with risk

**Fixed price** moves delivery risk to the vendor. The vendor commits to a defined scope for a defined price and absorbs overruns. That only works when the scope is defined well enough to price honestly. When it is not, a sensible vendor adds contingency, so the buyer pays for risk whether or not it materialises, and every change becomes a negotiation.

**Time and materials (T&M)** keeps the risk with the buyer. You pay for the effort actually spent. That is efficient when the work is genuinely uncertain, because you are not paying a premium for unknowns. The weakness is incentives. US federal procurement rules, which have thought about this for decades, state it bluntly: a time-and-materials contract "provides no positive profit incentive to the contractor for cost control or labor efficiency", which is why those rules require a ceiling price "that the contractor exceeds at its own risk" (FAR 16.601).

**A dedicated team** is a form of T&M where you reserve capacity, a stable team working on your priorities over months. Risk stays with the buyer, but you gain continuity and accumulated product knowledge, which matters for products that evolve continuously.

The same federal rules describe when a firm fixed price is suitable: when there is adequate price competition, reasonable comparisons with prior similar work, cost information that permits realistic estimates, or when "performance uncertainties can be identified and reasonable estimates of their cost impact can be made" (FAR 16.202-2). That last condition is the heart of the matter. Fixed price is right when uncertainty can be priced. When it cannot, someone is guessing.

The Risk Owner Test

Do not choose one model for a whole project. Break the project into workstreams (for example: the customer-facing app, the admin portal, the ERP integration, the AI feature, the data migration) and ask six questions of each.

1. Can you write the acceptance criteria today?

   If you can describe, in testable terms, what "done" means for this workstream, a vendor can price it. If acceptance depends on user research not yet run, or on decisions not yet made, it cannot be priced honestly yet.

2. Do you control every dependency?

   Workstreams that depend on third parties (an API you do not own, a partner's release schedule, data from another department) carry risk neither party controls. Our guide to hidden integration scope explains why integration is where estimates drift most.

3. Has this kind of work been done before, by this team?

   A login flow, a payment checkout or a standard admin dashboard is well understood. A novel algorithm, an untested AI capability or a first-of-its-kind workflow is not. Familiarity is what makes estimates reliable.

4. Will you want to change direction once you see it working?

   If you expect to learn from early users and adjust, a fixed scope works against you. Every insight becomes a change request. If the requirements are stable, such as a compliance-driven feature with a fixed specification, fixed scope is an advantage.

5. Is the main risk technical or commercial?

   Technical risk (will it work, will it scale) is best reduced by building something small first. Commercial risk (will customers use it) is best reduced by shipping early and iterating. Neither is well served by a large fixed bid up front.

6. Who is better placed to manage the risk?

   This is the deciding question. If the vendor has done this exact work many times, the vendor can manage the risk and should price it. If the risk depends on your organisation's decisions, data or partners, the vendor cannot manage it, and asking them to own it only buys you a contingency premium.

Reading the answers

For each workstream, count how many of the first five questions point toward certainty: criteria written, dependencies controlled, familiar work, stable direction, low technical and commercial risk. Then use question six to confirm.

• **Mostly certain:** fixed price. The vendor can own the risk and should. A fixed-cost engagement gives you budget certainty without paying for unknowns that do not exist.
• **Mixed:** time and materials with a ceiling. Agree an estimate, a cap, and a checkpoint where both sides review progress before more budget is committed. Our time and material model is structured this way.
• **Mostly uncertain or continuously evolving:** a dedicated team. Reserve capacity, set priorities every sprint, and measure outcomes rather than hours. See how our dedicated team engagements work.

How to run the test in one workshop

You do not need a vendor in the room to run the Risk Owner Test. A two-hour internal session is usually enough to produce a useful first pass.

• **Bring the right people.** Someone who owns the budget, someone who owns the product decisions, and someone who knows the existing systems and data. Without the third person, dependency answers will be optimistic.
• **List the workstreams on one page.** Keep them at the level a vendor would price separately. Five to ten is typical for a mid-sized build.
• **Answer the six questions for each, in writing.** A grid works well: workstreams down the side, questions across the top. "Probably" counts as no.
• **Mark the unknowns that block pricing.** These become the agenda for a discovery phase, and they are exactly what you should ask vendors to address in their proposals.
• **Decide the provisional model per workstream.** Then share the grid with shortlisted vendors and ask where they disagree. A vendor who challenges your answers with specifics is usually one who has done the work before.

The grid also changes the vendor conversation. Instead of comparing headline prices built on different assumptions, you are asking every bidder to price the same risks in the same structure, which makes proposals genuinely comparable.

The split contract: how mature buyers combine models

The strongest structure is often a combination, applied workstream by workstream and phase by phase.

**Phase one: a priced discovery.** A short, fixed-price engagement to produce acceptance criteria, an architecture, integration findings and a risk register. This turns uncertainty into scope. Our business analysis service exists for exactly this step.

**Phase two: fixed price for what is now certain.** The workstreams that discovery made well defined, such as core screens, standard integrations and admin tools, can be fixed-priced with confidence.

**Phase three: capped T&M for what remains uncertain.** The novel feature, the difficult integration, the AI capability that needs experimentation. Work in short cycles against a cap, with the option to stop if the results do not justify more spend.

**Phase four: a dedicated team after launch.** Once the product is live, a stable team handles the roadmap, improvements and support.

This structure is common for MVP development, where the core product is predictable but product-market fit is not, and for AI and ML projects, where model performance on your data cannot be known until it is tested.

Red flags in a vendor's pricing proposal

Read every proposal, including ours, against these signs.

• **A fixed price for undefined work.** If the vendor has not seen your integrations, data or user research, the number is either padded or wrong.
• **T&M with no cap and no checkpoints.** You carry all the risk and have no structured moment to stop.
• **No assumptions list.** Every honest estimate rests on assumptions. If they are not written down, they will surface later as change requests.
• **A single model for everything.** A one-model proposal for a multi-workstream project usually means nobody analysed the risk.
• **Change requests priced at a premium rate.** A low fixed price with expensive changes shifts cost to the phase where you have least negotiating power.
• **Silence on security and IP.** Whatever the model, the contract should say who owns the code and how your data is protected. Moweb is ISO 27001 certified; our approach is on our security page.

Questions buyers ask about software pricing models

Is fixed price always more expensive?

Not always, but it includes a premium for the risk the vendor absorbs. When scope is clear that premium is small. When scope is vague it can be large, and you pay it even if the risk never materialises.

Does time and materials mean an open-ended budget?

It should not. A well-run T&M engagement has an estimate, a ceiling, regular reporting and agreed points to review whether to continue.

Can we switch models partway through?

Yes, and it is often sensible. Discovery may start fixed, development may move to capped T&M, and post-launch work may move to a dedicated team. Agree the switching rules in the original contract.

Which model gives us the most control?

T&M and dedicated teams give you the most control over priorities. Fixed price gives you the most control over the budget for a defined scope. The Risk Owner Test tells you which kind of control each workstream needs.

How do we compare proposals that use different models?

Normalise them. Ask each vendor for their estimate, their assumptions and their contingency, then compare the risk each one is asking you to carry rather than just the headline number.

Run the Risk Owner Test on your project with us

If you are weighing proposals or planning a build, send us a short description of the project and its main workstreams. A senior member of our delivery team will run the Risk Owner Test with you, recommend the right model for each workstream, and show you where a short discovery phase would remove the most uncertainty. If a fixed price is the right answer for all of it, we will say so.

Talk to us about structuring your engagement, or explore how we deliver across product engineering and the projects on our case studies page.