How do you get an agreed price for technical work without it being either a guess padded for safety, or a trap that gets "discovered" halfway through?

Every owner who has commissioned software work has met both failure modes: the vague estimate that doubled, and the fixed quote that covered only part of what anyone reasonably meant. Between them sits a workable arrangement — fixed scope, fixed price — that is neither magic nor luck. It has prerequisites: what must be true before a price can honestly be fixed, and how to tell whether a provider has done that work or is just hoping.

Why the usual models fail

Two arrangements dominate, and both fail SMEs predictably:

  • Time and materials. You pay for hours, and the risk of underestimation is entirely yours. The meter keeps running while scope debates happen. It can suit genuinely exploratory work; for bounded problems it transfers risk in the wrong direction.
  • The confident fixed quote over fog. A price named before anyone examined the system, with the gap "discovered" partway through — at which point you are committed and negotiating from weakness. The trap is not the fixed price; it is the fixed price over unfixed uncertainty.

The pattern is worth naming: a price can only be as honest as the understanding beneath it.

What makes a scope fixable

Three conditions make a fixed scope possible — not comfortable, but possible:

  • A bounded domain. The work touches a defined system, workflow or integration — something with edges. "Improve our operations" has no edges and cannot honestly be priced; "capture web enquiries into the CRM with deduplication" does.
  • A written baseline. How the process works today, measured. The baseline anchors every later conversation about what changed, and exposes hidden complexity before it is priced, not after.
  • Acceptance criteria you can test. The written conditions under which the work is called done. If neither party can say in advance how they would know the work succeeded, no honest price exists yet.

When these three exist, a fixed price is arithmetic, not a gamble. When they do not, any fixed price is a bet — and the provider is betting with your money.

The paid diagnostic: pricing uncertainty before the quote

This is why a paid diagnostic step exists. A structured review — Cooper Agile's Technical Review is built for exactly this — examines the system, measures the baseline and drafts the acceptance criteria before a fixed quote is issued. The diagnostic prices the uncertainty. Sometimes the work is clean; sometimes a tangle surfaces that changes the scope or the decision to proceed. Either outcome is value: certainty bought before commitment. And if a provider offers a firm fixed price over a system they have never examined, you now know what they are doing — transferring the risk of their own ignorance to you.

You do not need a consultant to begin: the 60-second scoping tool walks through the bounded-domain questions and tells you whether what you have is fixable yet.

Change control in plain language

Fixed scope frightens buyers for one reason: what if we forgot something? The answer is a written change rule, agreed up front, with two branches:

  • A defect. The work does not meet the agreed acceptance criteria. The provider's problem, at the provider's cost — that is what a fixed price means.
  • A new request. Something the criteria never covered: legitimately new work, priced as a fixed add-on quote, or scheduled as a later FORT — one bounded outcome per fortnight.

Two branches, agreed in advance, kill most mid-project warfare. "Discovered work" claims get tested against the criteria: fail them and it is a defect; exceed them and it is a change with a written price.

Constraints and trade-offs

Fixed scope buys predictability, and its price is paid at the front: you must invest in the framing before the building. That means effort from you — the process owner who knows the workflow, the time to agree criteria, the discipline to route new ideas through the change rule instead of around it. Owners who skip the framing get the trap version, every time.

Illustrative example: a services firm wants its inbound leads followed up consistently: enquiry acknowledged within the hour, personal follow-up within two business days, a manager alert when either slips. The firm pays for a review first; it measures the pipeline, drafts testable acceptance criteria, and surfaces one hidden complication — enquiries arrive through two systems never reconciled. The fixed quote covers the agreed scope, reconciliation included. Mid-project, the firm asks whether the workflow can also score leads by value. It can — a new request, quoted separately and scheduled as the next FORT, not absorbed silently into the current price. The work ships on scope and on criteria; the enhancement arrives two weeks later, priced in the open. No blowout — because the uncertainty was priced before the quote, and the changes were priced as they arose.

Your action checklist

  • Write the outcome as one sentence with edges: a system, workflow or integration, not a theme.
  • Measure the baseline before asking anyone for a price.
  • Draft acceptance criteria you could test tomorrow, and have the outcome owner sign them.
  • Ask what each provider examined before naming a number — and be wary of firm prices over unexamined systems.
  • Commission a paid diagnostic before a fixed quote, so uncertainty is priced first.
  • Agree the change rule in writing: defects are the provider's cost; new requests get fixed add-on quotes or later FORTs.
  • Route new ideas through the change rule instead of around it.
  • Decide the success review date before work starts, and hold it.

If you want the uncertainty priced before the commitment, our Technical Review examines the system, baselines the process and drafts the acceptance criteria that make a fixed quote honest. And if you want to test whether your idea is ready, the scoping tool takes sixty seconds and tells you plainly.