Most disputes we have seen between a client and an agency were not caused by bad code. They were caused by a scope document that described what would be built without describing what would not be, and by an estimate that nobody could take apart.
Here is what we think a scope has to contain before either side signs it. This applies whether you are working with us or not — if you are evaluating another agency's proposal, these are the five things to check for.
1. A list of what is explicitly out
Every scope lists what is included. Very few list what is excluded, and the exclusions are where the arguments come from. If the document does not say whether an admin panel, a data migration, or an iOS build is out of scope, both sides will assume the answer that suits them.
Ask for the exclusions in writing. A team that will not write them down either has not thought about it or is planning to charge you for it later.
2. An estimate broken down by area
A single number for the whole project is not an estimate, it is a bid. You cannot negotiate with it and you cannot cut anything out of it.
A useful estimate splits the work into areas — authentication, the admin interface, the reporting, the integrations — with hours against each. That lets you look at a line, decide it is not worth what it costs, and remove it. We have had clients cut a third of a project this way, and they were right to.
3. What happens when the scope changes
It will change. The question is only whether the process for it was agreed in advance.
The version we use: nothing outside the written scope gets built until we have told you what it costs and you have said yes. It sounds bureaucratic and it takes about ten minutes per change, and it is the single biggest reason our projects finish near their estimate.
4. Who owns what, from when
Your repository, your infrastructure, your accounts, from the first commit — not handed over at the end. This matters more than it sounds like it does. A handover that happens on the last day is a handover that can be held over you, and it also means nobody has tested whether the thing actually runs anywhere but the agency's laptops.
5. What happens after launch
Ask directly: what does support cost after this ships, and for how long are bugs free? A team that has not thought about the answer is a team that is planning to stop returning your emails in week three.
We give thirty days of bug fixes at no charge after handover and quote maintenance separately. Whatever the answer is, get it in the document.
None of this requires trust. That is the point of writing it down. If you want to talk through a scope you have been handed — even one from someone else — send it over and we will tell you what we would push back on.