How do you price a fixed-scope build?

Fixed scope is a defined agreement

A fixed price transfers specified delivery risk to the supplier, but it does not make ambiguous work certain. The commercial boundary needs outcomes, included capabilities, acceptance evidence, environments, responsibilities and exclusions. A list of screens is insufficient because authentication, permissions, migration, integrations, performance and operation can dominate effort. The estimate should be traceable to complete vertical slices and enabling work. If one party interprets a phrase such as reporting or integration more broadly than the other, apparent price certainty becomes a dispute deferred until acceptance.

Discovery provides the evidence needed to price responsibly. The team inspects source systems and data, maps critical workflows, records non-functional requirements and tests risky assumptions. External interfaces are checked against actual documentation and access rather than vendor names. Prototypes resolve interaction uncertainty; spikes resolve technical uncertainty. The resulting plan states what remains unknown and who bears its consequence. Where a material uncertainty cannot be investigated, it can be excluded, priced as an option or handled under a time-based allowance instead of hidden inside an arbitrary fixed total.

Estimate the whole delivery system

Engineering estimates include analysis, implementation, review, automated testing, deployment, documentation and defect resolution. Project time also includes business decisions, supplied content, security review, user acceptance and third-party access. Some are client responsibilities but still affect elapsed delivery. Dependencies are sequenced and the critical path is identified. Contingency reflects named uncertainty rather than a generic addition. Commercial overhead, warranty obligations and payment timing may affect price even though they do not alter engineering effort, so effort and price should not be treated as interchangeable numbers.

• Define acceptance through observable business outcomes and quality constraints.
• State data, access, content and decision responsibilities with required dates.
• List supported browsers, environments, integrations and migration populations.
• Attach assumptions and exclusions to the capabilities they affect.
• Describe warranty, support and operational ownership after acceptance.

Acceptance must be testable

Acceptance criteria should identify inputs, expected outcomes and relevant failure paths. Subjective phrases such as intuitive, fast or seamless need an agreed interpretation or measurable constraint. Acceptance also covers accessibility, security, compatibility, audit evidence and data reconciliation where relevant. A review period and defect classification avoid treating minor presentation issues like failures of core operation. Acceptance is not a mechanism for introducing requirements that were absent from scope, nor should it permit delivery of technically present features that cannot complete the agreed business process.

Change control protects both parties

Learning continues during delivery, and some changes are valuable. A change request describes the revised outcome, schedule and price effect before implementation. Small substitutions may be neutral if they genuinely remove equivalent work, but accumulated informal requests distort the plan. The supplier should not use change control for clarifications already implicit in explicit acceptance criteria. Conversely, a new role, integration, data source or workflow branch is substantive even if its interface appears small. Keeping a decision log makes the boundary visible and allows priorities to change deliberately.

Structure delivery around evidence

Milestones should correspond to reviewed capabilities or risk retirement rather than elapsed calendar dates alone. Early increments establish environments, architecture and difficult integrations. Regular demonstrations use representative data and feed acceptance preparation, without converting every informal comment into scope. Payment stages can align with agreed evidence while preserving enough continuity to avoid incentives for premature sign-off. Progress reporting should show accepted outcomes, open decisions, risks and forecast, because a high count of completed technical tasks can conceal that no complete workflow is ready.

Know when fixed scope is unsuitable

Research, early product exploration and programmes dependent on unknown legacy behaviour are poor candidates until uncertainty is reduced. A capped discovery, time-based delivery or phased contract may provide better control. Fixed scope suits a bounded outcome with accessible stakeholders, inspectable dependencies and stable acceptance rules. Hybrid arrangements can fix a well-understood core while handling optional integrations separately. The contract form should follow the knowledge available, not a general preference for certainty. Transparent ranges and decision points often offer stronger financial control than a low fixed figure sustained by optimistic assumptions.