Fixed Price vs. Time and Materials: Budgeting Software Delivery

By Content Team · October 14, 2026

Choose fixed-price software delivery when the work, acceptance criteria, and dependencies are sufficiently understood to price a defined outcome. Choose time and materials when important requirements or technical constraints still need discovery, provided spending and progress are actively governed. A phased combination can be sensible when different parts of the project carry different levels of uncertainty.

The pricing model should match the evidence available about the work. A fixed number does not remove unknown integrations, and an hourly rate does not create a useful product backlog. Business leaders need a way to compare both models against the same delivery outcome.

Make the scope concrete before comparing prices

Imagine a distributor replacing spreadsheet-based order approvals with a portal connected to its CRM and ERP. “Build an approval portal” leaves unanswered questions: Which users can approve which orders? Where is customer credit status held? How are partial shipments represented? What happens if the ERP is unavailable?

Turn the request into observable acceptance cases. For example: an authorized approver can review an order, see its current status, approve within an assigned limit, and receive confirmation that the ERP recorded the decision. A failed write must remain visible and recoverable. Define security, audit history, migration, and operational support alongside the screens.

List assumptions separately from confirmed facts. Access to a vendor sandbox, stable API documentation, clean customer identifiers, and timely business decisions are dependencies with owners. They should appear in the estimate rather than emerge as surprises after development starts.

When fixed price fits

Fixed price is easier to evaluate when the deliverable can be bounded and tested. Examples include implementing a documented integration, replacing a known report, or delivering a small workflow after discovery has resolved the major uncertainties.

Ask what the quoted price includes: design, testing, migration, deployment, training, documentation, and post-launch defect handling. Identify exclusions and the process for assessing changes. A proposal with a lower headline price may leave more work to the buyer.

Milestones should correspond to accepted deliverables, not merely elapsed time. For the portal, a useful milestone might be a complete approval flow in a test environment with agreed failure cases demonstrated. A collection of screenshots proves much less.

Fixed price becomes harder to manage when business rules are unsettled or a third-party platform has not been inspected. In that situation, price a bounded discovery phase first. Its deliverables should include an integration proof, workflow map, prioritized scope, acceptance cases, and a revised estimate.

When time and materials fits

Time and materials can fit exploratory product work, legacy-system modernization, or integrations where discovery continues during implementation. The buyer pays for agreed work at agreed rates, so the controls need to make effort and outcomes visible.

Set a funded increment, a prioritized backlog, and a decision owner. Review working software frequently. Track actual spending, forecast remaining effort, and agree on the point at which the team must stop for a funding or scope decision. A spending ceiling should be explicit; neither party should assume an estimate automatically serves as one.

Iterative delivery supports learning, but it still needs quality standards. The Scrum Guide describes inspection and adaptation, a shared Definition of Done, and scope refinement as teams learn. Those delivery practices can support either commercial model; Scrum itself does not specify how the work must be priced.

An effective review asks what now works, what evidence changed the forecast, and what should be built next. Counting hours without examining accepted outcomes gives a weak picture of progress.

Compare the full cost of reaching the outcome

Request estimates using the same assumptions and deliverables. Include internal staff time, third-party licenses, cloud infrastructure, integration fees, data cleanup, migration, training, and ongoing support. Identify which costs are one-time and which continue after launch.

The U.S. Government Accountability Office's Cost Estimating and Assessment Guide emphasizes a technical baseline, explicit assumptions, risk analysis, and updating estimates with actual costs. Although written for program-cost management, these disciplines are useful when reviewing a business software estimate.

For a time-and-materials proposal, calculate the planned effort multiplied by the relevant rates, add known external costs, and test scenarios where uncertain work expands. For fixed price, examine the cost and delay consequences of plausible changes. Use the same scenario in both proposals, such as discovering that customer records cannot be matched reliably across systems.

Do not treat a contingency as permission to spend. Define who can release it and what evidence is required. Ask for a forecast range where uncertainty is material, with the assumptions that move the estimate toward either end.

Use a hybrid model at real boundaries

A useful hybrid can start with a fixed-scope discovery engagement, continue with capped iterative delivery for uncertain integrations, and price a stable rollout package after the pilot. Each transition needs a decision gate and updated acceptance criteria.

Avoid dividing work solely by department. A fixed-price interface and an open-ended integration behind it can leave responsibility unclear when the end-to-end workflow fails. Assign one owner to acceptance of the complete business process, even if several commercial work packages support it.

Before signing, have the appropriate commercial or legal reviewers check ownership, licensing, access, handover, termination, and change provisions. This article offers delivery-planning guidance, not contract interpretation.

Make the first increment a decision tool

Pilot one complete order-approval path with representative users and realistic test data. Include authentication, permissions, an ERP write, failure recovery, and an audit record. Establish the manual baseline before evaluating improvement.

Track approval cycle time, manual touches per order, integration exceptions, defects found after acceptance, and the gap between forecast and actual spending. Use delivery measures such as change lead time and failed-deployment recovery where relevant; DORA's metrics guide explains these as improvement tools rather than a substitute for business outcomes.

At the decision gate, compare accepted capability with remaining uncertainty. Continue only when the next increment has a defensible scope, budget, owner, and expected business benefit.

Frequently asked questions

Is fixed price always cheaper?

No. Compare the complete scope, assumptions, exclusions, change process, and operating costs. The headline price alone does not establish the cost of reaching the business outcome.

Can time and materials have a budget limit?

Yes, when the parties explicitly agree on a ceiling, reporting cadence, and stop-or-approve mechanism. Clarify whether a number is an estimate, a funding limit, or a contractual cap.

Can an agile project use fixed pricing?

Yes. Delivery practices and commercial terms are separate decisions. The scope boundary, acceptance process, and rules for exchanging or adding work need to be clear.

What should discovery produce?

A useful discovery phase resolves key workflow and technical questions, tests risky integrations, defines acceptance cases, and produces a prioritized delivery plan with documented assumptions.

Scope the next decision

Hexagon's custom software development approach begins with business workflows, systems, and delivery planning. Discuss your project with the intended outcome, known constraints, and unresolved dependencies to identify a practical first phase.