What a fixed-scope quote should contain
A quote is a promise about what will be built. Eight things a written, fixed-scope quote should state before any work starts.
A quote is a promise about what will be built, by when and for how much. When it is vague, the uncertainty does not disappear. It moves to you, and it usually returns later as a change request or a surprise on the invoice.
A good fixed-scope quote is a short, plain document. Here is what it should contain.
1. The outcome and who it is for
One or two sentences on what the project must achieve and for whom. Everything else in the quote should trace back to this. If a feature cannot be connected to the outcome, question it.
2. What is in scope, and what is not
List the pages, features, integrations and platforms that are included. Then list what is explicitly excluded. The second list prevents most disagreements, because it turns unspoken assumptions into written ones.
3. Deliverables and acceptance criteria
Name what you will receive: working software, source code, documentation, access to environments. For each important deliverable, state how it will be judged finished. “The checkout completes a card payment in the test environment” is an acceptance criterion. “The checkout works well” is not.
4. Assumptions and dependencies
Every project rests on things outside the supplier’s control: content arriving on time, access to a third-party system, decisions made within an agreed number of days. Write them down, together with what happens if one of them changes.
5. Timeline and milestones
Break the work into stages with dates, and say what you can see at the end of each one. Small, visible increments let you confirm direction early instead of discovering a problem at the end.
6. Price and payment schedule
A fixed scope should come with a clear price and a payment schedule tied to milestones, not to the passing of time. Check what is included in the price: hosting, licences, third-party fees and revisions are often treated differently.
7. How change is handled
Requirements will change. A good quote says how: a change is described, estimated and approved in writing before work on it begins. That keeps the original price meaningful and keeps you in control of any additions.
8. Handover and support
State what happens after launch: documentation, training, a warranty period for defects, and the terms of any ongoing support. Software that is delivered but cannot be maintained is a cost deferred, not a cost saved.
Using the list
When you compare quotes, compare them against these eight points rather than against the headline price. The cheapest quote is often the one that has left the most questions unanswered. At Kodaura we write quotes against a written scope for exactly this reason, and we are glad to walk through the same questions with you before you decide.
This article is also available in Greek. Read it in Greek
Back to the blog