You are holding two quotes for the same system. One is a single paragraph with a low number. The other is a list of nouns: intake, reading, review, approval, export. Neither tells you which one is real. How to scope a software project comes down to one habit: write down the work, document by document and step by step, before anyone writes down a number, because a fixed price is only as honest as the map behind it.
A fixed price is a result, not a contract type
Most writing on this compares contracts, fixed price against time and materials, with a table of who carries the risk. The comparison is fair, and it skips the step that decides everything. A fixed price does not make the work smaller or less uncertain. It moves the uncertainty from you to the builder, who will charge for carrying it.
If nobody mapped the work, the number is a guess with a buffer on top, and you are paying for the buffer.
Buyers already sense this. Futurum's 2H 2026 survey of enterprise software decision-makers, published in August 2026, found that buyers who pay separately for AI features want a predictable line item: a ceiling on what an unfamiliar feature can cost in a bad month. That survey is about software vendors' pricing, not custom builds, so read it as the mood and not as proof.
The mood is easy to follow. The less anyone knows about a cost, the more they want a cap on it, and a cap is only worth having when someone has looked at what sits underneath.
What a scope has to say
A scope is not a feature list. Read it the way a stranger would, someone who joins in week three. Could they tell what comes in, what happens to it and what is left out? A feature list says "invoice processing". A scope says that invoices arrive as email attachments and phone photos, that someone in accounts checks each one against a purchase order by hand, and that the system will read the amounts, flag the mismatches and hand them back to that same person.
Four things have to be on the page. The inputs: every document that arrives, in what form and from whom, down to the phone photo and the scan with pen marks on it. The steps: what happens to each one, who does it, and where it passes from one person or tool to the next.
The exclusions: what the system will not do, in the same plain words as everything else. The assumptions: what has to be true for the number to hold, such as real sample documents on day one and one person who can answer a question within a day.
The assumptions are the part most quotes lack, and they are where a fixed price actually breaks. When one turns out false, the scope should already say what happens next: the price is reviewed, or the item moves out. Without that sentence, every surprise becomes an argument.
Map the work before you price it
This is the longest part of the job, and it cannot be done from a meeting room. The documents have to be in front of you. Our Audit exists for this: in 48 hours it maps the documents coming in, the hands each one passes through, the retyping and the places where work stalls, and it ends with a build plan the client keeps. The services page shows where it sits next to the build.
The same habit shows in how Stay Funded 360 was run. The system was scoped, built and tested on real data in 10 working days, and the real data was the point. The cover sheet was matched line for line against the packet the approvers had already signed off, so the format was never an opinion anyone had to defend later.
Nobody on the funder's side had to learn anything new. That one sentence costs a day to write. Leave it out and the project ends up arguing about the format after the money is spent.
A map also changes what you can price. Once every step has a person and a handoff attached, the heavy ones show up: the retyping, the chasing, the step that waits on one person's inbox. Those can be priced. "Make it better" cannot.
What we leave out on purpose
Every project we have shipped has something left out in writing. In the Compliance Portal, reminders before a credential expires run on one fixed schedule for everyone. We did not build a different lead time for each requirement, because the client could not yet say which requirements needed one. The evidence packet layout stays plain until the regulator's exact format is confirmed.
In Stay Funded 360, what the funder approved or disallowed is still entered by hand, because it arrives as pen marks on a scan, and sending the packet is still a person's job.
None of that is a hole in the scope. Each item is a sentence that says "not in this price", with its reason, and the buyer reads it before signing. An exclusion written down is a conversation you have once. One discovered later is a change order.
When fixed price is the wrong tool
Some work should not be quoted at a fixed price. If the system does not exist yet and nobody has looked at the documents, or the job is exploratory by nature, a fixed number is the builder's guess dressed up as a promise. The honest options are a paid discovery that ends with a written scope, or an hourly arrangement with a cap you both agree on. Both say out loud that the map is not drawn yet.
The same logic holds one level up. Bain's August 2026 look at AI pricing says that pricing against outcomes works only when the outcome is observable, attributable to the software and contractible, and that most workflows do not meet that test. It too is about vendors' pricing, not custom builds.
The lesson still carries over: you cannot put a price on a result nobody can see, any more than on a scope nobody drew.
Where to start
Take the one process you are about to buy a system for, and ask three things of any quote you hold:
Which documents does it say arrive, and in what form?
Who does each step today, and where does it pass to someone else?
What does it say the system will not do?
A quote that answers all three has been through your work. One that answers none has been through a template. Neither of the two on your desk is a scope yet, so ask both for those answers and see which comes back with documents instead of adjectives.
If you would like a second pair of eyes on the process before you ask anyone for a number, we can map it with you in a 30-min call.
Frequently asked questions
How do you define the scope of a software project?
List what comes in, what happens to it, what the system will not do and what must be true for the price to hold. Write it so a stranger could build the same thing from it.
What is a project's scope?
It is the agreed boundary of the work: the documents, steps and results that are in, and the ones that are out. A scope that only lists what is in is half a scope.
How do you write a scope that a fixed price can hold?
Map the work against real documents first, name the person at each handoff, and write the exclusions and assumptions as plainly as the features. The price then follows from the map and not from a buffer.
What happens when the scope changes after you sign?
The change is priced on its own, which only works if the original scope says what was in and what was out. When it does not, the argument is about memory and not about a document.
When is time and materials the better choice?
When the work is exploratory or nobody has inspected the system yet. A paid discovery that ends in a written scope, or a capped hourly arrangement, is more honest than a fixed number nobody can back up.
