BUYER’S GUIDE

Software development pricing models: T&M vs fixed price vs milestone-based.

Before you compare vendors, it pays to decide how you want to buy. The pricing model you sign determines who carries the delivery risk, when you pay, and what happens when scope changes. This guide compares the three models used across the industry, in plain language, so you can walk into any vendor conversation knowing which contract shape protects you.

Last reviewed: August 19, 2026

Jump to the comparison How to choose

THE THREE MODELS

What each pricing model actually is.

Every software development contract is a version of one question: who absorbs the cost when reality diverges from the plan? The three models answer it differently. None of them is universally right; each fits a different shape of work and a different tolerance for risk.

Time and materials (T&M)

You pay for the hours the team works, at agreed rates, plus expenses. The contract fixes the rate, not the outcome or the total.

The vendor invoices on a cadence (usually monthly) for time logged. Scope lives in a backlog you can reprioritize at will. The engagement ends when you stop it, not when a deliverable lands.

WHERE IT WORKS

  • Maximum scope flexibility: change direction any week without renegotiating a contract.
  • Honest fit for genuinely undefined work: research, legacy rescue, ongoing product evolution.
  • No incentive for the vendor to pad estimates up front, because there is no estimate to protect.

WHERE IT BREAKS

  • Delivery risk sits with you: the total reflects how long the work actually takes, so overruns land on your budget.
  • The total cost is unknowable at signing. Budgeting is a forecast, not a commitment.
  • Requires real oversight from your side: someone has to watch velocity and burn, every week.

Best for: Work whose scope genuinely cannot be pinned down: exploratory builds, evolving roadmaps, and long-running product teams where you direct priorities continuously.

Fixed price

One price for one defined scope, agreed before work starts. The vendor commits to deliver the specification for the number, however long it takes.

The scope is specified in detail up front, the price is signed, and payment is typically split across a deposit and delivery dates. Anything outside the specification is a change order at additional cost.

WHERE IT WORKS

  • Total cost certainty at signing, which is what finance teams and boards want to see.
  • Delivery risk sits with the vendor: overruns are their problem, not yours.
  • Minimal ongoing oversight: you manage against a contract, not a backlog.

WHERE IT BREAKS

  • It only works if the scope is fully known on day one, which is rare for real software.
  • Vendors protect themselves by padding the price and defending the specification, so you pay a risk premium and fight over every change.
  • Quality is the pressure valve: when a fixed-price project runs late, corners get cut where you cannot see them.

Best for: Small, precisely specified projects with little unknown: a well-defined integration, a rebuild of an existing system, work you have done before in another form.

Milestone-based

The project is split into milestones, each with written acceptance criteria and its own price. You pay per milestone, when it is delivered and you accept it.

A paid scoping phase (often called a discovery phase or Sprint 0) produces the milestone plan: what each milestone contains, how it is tested, and what it bills. The build then delivers milestone by milestone. Scope changes become new milestones rather than disputes over the original price.

WHERE IT WORKS

  • Payment maps to delivered, working software, not to hours or promises. You never prepay for undelivered work beyond the current milestone.
  • The exit option is structural: stop at any milestone boundary, pay only for accepted work, and keep everything delivered.
  • Fixed-price discipline where it is honest (per milestone, where scope is knowable) and flexibility where it is needed (between milestones).

WHERE IT BREAKS

  • Requires a real scoping phase first, which costs money and time before the build starts.
  • Acceptance criteria have to be written well: vague criteria recreate the fixed-price dispute at every milestone.
  • Fewer vendors offer it, because it moves delivery risk from the buyer to the vendor.

Best for: Defined-scope product builds of real size: new products, major features, and rebuilds where you want cost control without pretending the entire scope is known on day one.

SIDE BY SIDE

The three pricing models compared.

The axes below are the ones that decide how a project feels six months in: who carries the risk, how predictable the spend is, and what happens when the plan meets reality.

Time and materials Fixed price Milestone-based
Who carries delivery risk You. Overruns are billed to you. The vendor, priced in as a premium. The vendor, per milestone.
Cost certainty None at signing. Forecast only. Total certainty at signing. Certain per milestone, planned for the whole build.
When you pay Monthly, for hours logged. Deposit plus schedule, regardless of state. On acceptance of each delivered milestone.
Scope flexibility Total. Reprioritize weekly. Rigid. Every change is a contested change order. Structured. Changes become new milestones.
Vendor incentive Paid for time worked. Alignment rests on trust and oversight. Protect the agreed specification. Ship accepted work to get paid.
Oversight you need High. Watch velocity and burn weekly. Low, until the dispute. Moderate. Test acceptance criteria per milestone.
Exit mid-project Anytime, keep whatever exists. Contract termination, often with penalties. At any milestone boundary, keeping all accepted work.
Best for Undefined, evolving work. Small, fully specified projects. Defined-scope builds of real size.
WORKED EXAMPLE

The same project under all three models.

Take a mid-size build: a B2B web product with a core workflow, two system integrations, and an AI feature, honestly estimated at around $80,000 of engineering work over four months. Here is how the three contracts play out when, in month three, a real scope change arrives.

Under T&M

You signed at a blended hourly rate with an $80,000 forecast. The change is absorbed into the backlog without friction, which is the model working. The integration ran two weeks longer than planned, so the forecast became $95,000, which you tracked through the weekly burn reports. That visibility is the model’s real requirement: the budget is a forecast you manage continuously, not a number the contract holds for you.

Under fixed price

You signed at $95,000, because the vendor priced the unknown into the number. The scope change triggers a change-order negotiation: three weeks of back and forth about whether it was "in spec", a $12,000 addendum, and a delivery date that slips while the paperwork settles. You had cost certainty on a scope that stopped being the scope.

Under milestone-based

A paid scoping phase set six milestones totaling around $80,000, each with acceptance criteria. Milestones one through four are delivered, accepted, and paid. The change becomes milestone seven, priced and accepted before it is built. The integration overrun is the vendor’s problem inside milestone five, because the milestone price was committed. Total cost moves only when you approve new scope.

The pattern generalizes. T&M asks you to manage the budget continuously, fixed price concentrates the negotiation into change orders, and milestone-based moves the total only through decisions you sign off on. Which trade-off fits is a real choice, and it depends on how defined your work is.

HOW TO CHOOSE

Four questions that settle the pricing model.

  1. 01

    Can the scope be pinned down at all?

    If the work is genuinely exploratory or the roadmap changes monthly, T&M (or a retained team) is the honest answer, and any vendor offering you a fixed number for undefined work is padding it. If the scope can be defined, keep reading.

  2. 02

    Is the project small enough to specify completely?

    For a two-to-six-week project you have done before in some form, plain fixed price works: the unknowns are small enough that the risk premium stays small. Past that size, a single fixed price forces both sides to pretend months of work are fully known on day one.

  3. 03

    Who do you want holding the delivery risk?

    Under T&M it is you, under fixed price and milestone-based it is the vendor. The difference between the last two is granularity: one bet on the whole project versus a series of smaller bets you re-decide at every milestone.

  4. 04

    What does exiting look like if the relationship sours?

    Ask every vendor this before signing anything. Under T&M you can stop anytime but own whatever half-finished state exists. Under fixed price, exit means termination clauses. Under milestone-based, exit is built in: stop at a boundary, pay for accepted work, keep everything delivered. If a vendor cannot answer the exit question plainly, that is the answer.

COST ESTIMATION

Why software development cost estimates vary so much.

Ask five vendors to estimate the same project and the numbers commonly spread threefold. The spread is rarely dishonesty. Estimates diverge because vendors assume different things about the unknowns: how clean your existing systems are, how much of the scope is genuinely decided, how much rework the feedback loops will generate, and how senior the team doing the work is.

That is why the most reliable cost estimation is paid, short, and done by engineers: a scoping phase that closes the unknowns before anyone commits to a number. A useful benchmark: a serious discovery phase for a mid-size build runs two to four weeks and costs in the low five figures, and it should end in artifacts you can take to any vendor, not a proposal that only works with the vendor who wrote it. Estimates produced on a sales call are marketing; estimates produced by engineering work are plans.

WHERE WE STAND

The model we use, and why.

Leanware is an AI Engineering Company, and we build under the milestone-based model, because it is the only one of the three where the vendor’s incentive and the buyer’s outcome point the same direction on a defined-scope build. Our version starts with Sprint 0, a fixed-scope, fixed-fee discovery sprint ($5,000 to $15,000, two to four weeks) that produces the closed scope, the acceptance criteria, and the milestone plan. The build then bills per accepted milestone, and you can exit at any milestone and keep everything delivered.

We also say plainly where milestone billing is the wrong instrument: an evolving roadmap with no honest milestones belongs on a retained team, and we run those engagements on a monthly retainer instead. The full detail of both models, including a concrete example milestone schedule and the exit terms, is on our engagement models page.

See what Sprint 0 includes Read our engagement models

FREQUENTLY ASKED

Common questions about software development pricing.

The questions buyers ask when deciding how to structure a development contract.

  • Which software development pricing model is least risky for the buyer?
    Milestone-based billing, for defined-scope work: you pay only for delivered, accepted milestones, and you can exit at any boundary keeping everything delivered, so your maximum exposure is one milestone. Fixed price caps your cost but concentrates risk into one bet on a specification, paid for through a risk premium and change-order friction. T&M is lowest-risk only when the work is genuinely undefined, because it never forces a false commitment, but it leaves the entire cost overrun risk with you.
  • Which pricing model is cheapest?
    For the same delivered scope with a competent vendor, T&M has the lowest sticker price because no risk premium is built in, but you carry the overrun risk that premium would have covered. Fixed price is typically 15 to 30 percent above an honest T&M estimate for the same work, which is the price of certainty. Milestone-based lands between them: milestone prices carry a smaller premium than a whole-project fixed price because the vendor commits to weeks of scope at a time, not months.
  • What is milestone-based billing in software development?
    A pricing model where the project is divided into milestones, each with written acceptance criteria and its own price, set during a paid scoping phase before the build. The vendor delivers milestone by milestone, and each milestone bills when the buyer tests it against the criteria and accepts it. Scope changes become new milestones rather than change-order disputes, and the buyer can exit at any milestone boundary keeping all accepted work.
  • Time and materials vs fixed price: which is better for a startup MVP?
    Neither is a clean fit. Fixed price forces you to fully specify a product you have not validated yet, and the change orders start the week your first user feedback arrives. T&M matches an MVP’s uncertainty but spends runway with no committed relationship between money and shipped scope. The milestone model was effectively designed for this case: a short paid discovery pins down the first milestones, you pay as accepted functionality ships, and pivoting means re-scoping future milestones you have not paid for.
  • What should a discovery phase cost before a software project?
    For a mid-size build, a serious discovery phase runs two to four weeks and, in our case, $5,000 to $15,000 as a fixed fee depending on complexity. Be wary at both ends: free discovery is sales qualification wearing an engineering costume, and open-ended hourly discovery has no structural reason to end. Whatever you pay, the test is portability: the deliverable should be usable with any vendor, not just the one who wrote it.
  • Can you switch pricing models mid-project?
    Yes, and it happens in one direction far more than the other: projects that start T&M and accumulate budget anxiety often move to milestones once the scope has firmed up. Going the other way, from fixed to T&M, usually signals that the specification collapsed. If you anticipate the switch, structure it at a natural boundary (a release, a phase end) and treat the scoping of the milestone plan as its own small, paid piece of work.
  • What questions should I ask a vendor about their pricing model?
    Five reveal most of what matters. When exactly do I pay, and what triggers each payment? What happens when scope changes, mechanically, in the contract? What do I keep if we part ways mid-project? Who absorbs the cost when a piece of work takes longer than estimated? And who wrote the estimate, a salesperson or the engineers who would deliver it? Vendors with buyer-aligned models answer all five without flinching.
  • Is a dedicated development team a pricing model?
    It is an engagement model with its own pricing shape: a monthly retainer for a stable team, effectively a structured form of T&M with continuity. It is the honest choice when the work is an evolving roadmap rather than a defined scope, which is why serious vendors offer it alongside milestone-based builds rather than instead of them. The right question is not which model the vendor prefers, but whether they match the model to the shape of your work.
TALK IT THROUGH

Not sure which model fits your project?

A 30-minute call with a senior engineer settles it. We walk through the shape of your work, tell you which contract structure protects you, and say so plainly if the answer is not us.

Tell us about your project. A senior engineer will review the shape of the work, tell you which contract structure protects you, and say so plainly if the answer is not us.

Get in touch Send Us a Message See our engagement models