A fixed-scope first phase protects both sides: the client knows the cost, the team knows the finish line. The scoping work beforehand is what makes the price honest.
Clients ask for a fixed price because they have been burned by open-ended projects. Teams resist fixed prices because they have been burned by scope that grew. Both are right, and the fix is the same: a first phase small enough to scope properly, with a written scope that both sides can hold the other to. This is how we go about it, and what we ask of a client before we commit to a number.
Pick the first phase by value, not by size
The first phase should be the smallest piece of the system that is useful on its own: the intake form that replaces paper, the report that replaces the spreadsheet, the quote generator that replaces the calculator. "Useful on its own" means someone will use it every day once it ships, which is the only way to learn whether the rest of the plan is right. A phase that delivers half of three features delivers nothing anyone can use.
What goes into the scope document
- Users and the job each one does, in a sentence each.
- Screens or steps, listed, with what each shows and what the user can do there.
- Data: the records, their fields, and where they come from and go to.
- Integrations, named, with the method (API, file import, manual) for each.
- Rules that the software enforces, written in plain language with an example.
- Not included: the list of things discussed and deliberately left for later. This section prevents most disputes.
- Acceptance: how both sides will agree the phase is done.
Where estimates go wrong
Integrations with systems nobody on the team has touched; data migration from a source nobody has inspected; "simple" reporting that turns out to need eight filters; approval flows with exceptions that only appear in week five. Each of these is a question to ask during scoping, and if the answer is "we are not sure", the honest response is a short paid discovery, not a fixed price with a large contingency hidden inside it.
Changes during the phase
Changes will come, and the scope document is what makes them visible. A request that is not in the document is a change: it is written down, estimated, and either added to this phase with a price and date adjustment or placed first in the next. Done consistently from the first week, this is not friction; it is the reason the fixed price can be kept.
What a client should expect to see
A scope document before the price, a weekly demo during the phase, a working system at the end that the people named in the scope actually use, and a list of what was learned that changes the plan for phase two. If a proposal offers a fixed price without the scope document, the price is a guess, and one side will pay for it.
Umer Farooq, CTO, eSquall
Published on October 31, 2026
