Fixed Price vs Time and Materials: A Decision Framework for Software Development

Most agencies pick a pricing model the way they pick a default font: by habit. Fixed price on everything, because clients ask for it. Or T&M on everything, because one bad fixed-price project left a scar. Either way, the bill shows up later as margin leaking out of projects where the model never matched the uncertainty.

This is not another overview of pricing models. It is a decision framework: concrete questions that tell you which model fits a specific opportunity, the estimation techniques each model demands, and how the choice should change the proposal you send. Answer them, and the model stops being a guess.

Start with where the uncertainty lives

The client’s preference is the wrong first question. Agencies lose margin in exactly two ways: quoting a fixed price on a scope they do not understand, and running T&M without a baseline the client trusts. Both come down to placing uncertainty badly.

So the framework starts with three questions about the work itself, not about the contract:

1. Can you enumerate the deliverables today? Not “we know roughly what an e-commerce platform contains.” Can you list the modules, screens, integrations, and acceptance criteria with names? If the estimate is a feature list with units attached, the scope is knowable. If it is a paragraph of ambition, it is not.

2. How stable are the requirements through delivery? Some scope is knowable but will move, like a product where the market is still being tested. Some scope is knowable and will not move: a regulatory report, a portal with fixed screens, a migration with a defined source and target. Stability is separate from clarity, and it changes the model.

3. How much of the work have you done before, in this exact shape? Rebuilding a billing module you have shipped six times is a different estimation problem from greenfield AI infrastructure. The question is not competence. It is whether your estimate draws on comparable history or on hope.

Plot those answers and the decision almost makes itself:

Fixed price: the estimation discipline it demands

Fixed price punishes guesswork hardest, because the risk premium is invisible until the project runs over. When the framework says fixed price, the estimation has to change from “a number” to “a structure”:

• Decompose to priced components, not hours. “Dashboard, 12 days” is a guess. “Billing module, 60 to 85 hours across our last four builds, including PCI-DSS scope” is a reference. Component-based estimation turns fixed price from a bet into a statement about your own delivery record. If you cannot quote any line item from history, you are not ready to go fixed price on that project.
• Write assumptions into the proposal, not the drawer. Every fixed-price estimate rests on assumptions: API documentation is complete, content arrives from the client by a date, browser support covers the last two versions. List them in the proposal with the cost impact each one triggers. That list is what makes change control possible later. Without it, every scope movement turns into a negotiation about who pays.
• Price the buffer visibly or not at all. A hidden buffer protects you but destroys trust the moment the client sees a low estimate followed by change requests. A visible contingency, such as “we estimate 20 days of work plus 5 days of contingency for the payment provider’s API risk,” protects both sides, and the client still sees what they are buying.

T&M: the estimation it still requires

T&M is often chosen because the team does not want to estimate. That is the fastest way to turn a flexible contract into an unhappy client. T&M without a baseline looks like a blank check from the client’s point of view, and clients who feel that way start auditing hours and questioning invoices.

T&M still needs an estimate. It needs a baseline built from the same decomposition discipline: a well-formed range, such as “110 to 145 hours for phase one.” The difference is what the baseline is used for:

• It sets the budget envelope. The client agrees to a range, and you agree to re-forecast when the range moves instead of pretending it will not.
• It makes spend visible against progress. Weekly reporting that shows hours consumed against the baseline (“we planned 40 hours for the integration, we are at 34, here is what remains”) stops T&M from feeling like a meter running with no destination.
• It gives you a change mechanism for free. When scope genuinely grows, the baseline is the agreed starting point: the client sees the delta and approves it before the work starts, instead of discovering it on the invoice.

Done right, T&M with a visible baseline is more honest than fixed price. It prices the actual cost of change instead of burying it in a risk premium. Done wrong, it is a blame machine.

Hybrid: fixed-price discovery, T&M delivery

The framework’s third question, have we done this before, is where most agencies go wrong in both directions. They sell fixed price on greenfield work, on a hope-based estimate, and watch margin bleed later. They also run T&M on projects whose discovery was already done, paying for certainty they already own.

The hybrid answers both mistakes: price discovery at a fixed cost, deliver the build on T&M. Discovery covers interviews, workshops, architecture, and a document with acceptance criteria. It is predictable and bounded. It can be quoted from experience even when the product is new. The build after discovery is exactly where the scope becomes enumerable, until it hits the market and moves. Charging fixed price for discovery also creates the thing every good fixed-price project needs: a written, agreed scope before development starts, produced by a phase you were actually able to price.

The other hybrids fit the same logic. T&M with a capped budget puts a ceiling on the client’s exposure while keeping flexibility, though the agency eats the overrun above the cap, so the cap must be priced with real history. Milestone-based fixed pricing fixes only the well-understood slices and leaves the uncertain ones open.

Let the model shape the proposal

A fixed-price proposal and a T&M proposal are different documents, and sending the wrong shape is how model mismatches get discovered late.

A fixed-price proposal must lead with what protects the number: the scope breakdown with priced components, the assumptions list with cost impacts, the change-request process, and what happens to the price if an assumption fails. If a fixed-price proposal reads like a brochure, the client will treat the number as a promise without reading the conditions, and the first change request will feel like a betrayal instead of a documented step.

A T&M proposal must lead with what protects trust: the baseline range, the reporting cadence, the budget guardrails, the re-forecasting trigger, and the weekly progress view. If a T&M proposal lists only rates and a vague plan, the client signs up for an invoice with no destination, which is the exact fear that makes buyers reject T&M.

In both cases the estimate carries the proposal. The model determines which parts of the estimate are front and center, but the underlying discipline (decomposition, historical components, visible assumptions, forecast vs actual) is the same. Agencies that treat the model as a presentation layer over one solid estimation process win twice: the proposal is defensible, and the contract matches reality.

Recommendations

1. Run the three-question test before you discuss the contract: deliverables enumerable, requirements stable, comparable history. Two “yes” answers point to fixed price or a fixed-price phase. Two “no” answers point to T&M or a hybrid.
2. Never sell fixed price without a component-based estimate drawn from your own project history. A number without a source is a bet.
3. Never start T&M without a baseline range the client has seen. T&M without a baseline is a blank check; T&M with one is the honest version of fixed price.
4. Offer fixed-price discovery plus T&M delivery on greenfield work. It prices what you can price and keeps the build flexible where it will actually change.
5. Rebuild the proposal around the model: assumptions and change control in a fixed-price offer, baseline and reporting in a T&M offer.

Summary

The fixed price vs time and materials decision comes down to where uncertainty lives in the project, not to the client’s preference or a house style. Knowable, stable, familiar scope prices well under fixed price. Emergent, moving, novel scope needs T&M or a hybrid, with a baseline that protects both sides. The estimation discipline underneath is identical in every case: decomposition, history, visible assumptions. The model just decides what the client sees of it.

If you want to see what a structured, component-based estimate looks like when it is the backbone of both contract types, fixed price and T&M alike, it is worth testing a CPQ tool built for software agencies that keeps the estimate, the assumptions, and the budget baseline in the same place as the offer.