Three developers quoting the same brief at 40,000, 90,000 and 250,000 are usually not disagreeing about their rates. They are quoting three different products, because the brief allowed three readings.
Why the spread happens
A brief that says "users can upload documents" leaves every costly decision open. How large? What formats? Is there virus scanning? Preview in-browser or download only? Versioning? Who can see whose files? Retention and deletion?
A developer quoting cautiously assumes the simple reading. One quoting defensively assumes the complex one and prices for it. Both are behaving reasonably. The buyer concludes the expensive one is overcharging, picks the cheap one, and discovers the gap during development — at which point it becomes a change request.
The five things that have to be pinned down
- User roles and what each can do. Not "admin and user" but a list of actions per role. Permission logic is a large share of the work in most business applications, and it is invisible in a feature list.
- The main workflows, step by step. Write the sequence a user actually goes through, including what happens when something goes wrong — a rejected payment, an expired session, a duplicate submission.
- The data. What is stored, what is required, what validation applies, how long it is kept. A field list is more useful than a screen description because screens change and data does not.
- External dependencies. Payment, messaging, maps, existing systems to connect to. Each one carries approval time and failure handling that has to be budgeted.
- Acceptance criteria. How you will decide the thing is finished. This is the section most often omitted and the one that prevents the most arguments.
Volume and performance, stated as numbers
"Should be fast" and "should handle a lot of users" cannot be quoted or tested. Numbers can:
- Expected users in year one, and concurrent users at peak.
- Records expected in the largest table after a year.
- Acceptable response time for the slowest common operation.
- File sizes and total storage.
These change the architecture. An application designed for 200 users and one designed for 200,000 differ in database design, caching and hosting cost, and building the second when you need the first wastes money that could have gone into features.
What a spec should not contain
Two things that make specs worse:
Technology choices, unless there is a real constraint. Specifying a framework because it was recommended removes the developer's ability to propose something better suited. If there is a genuine constraint — an existing system, an in-house team who must maintain it — state the constraint rather than the conclusion.
Pixel-level design in a functional spec. Design and function are best separated. A spec that mixes them makes both harder to review and turns every visual preference into a functional change.
The sections that cause disputes later
Consistently, in order:
- Reporting. "Reports" in a brief becomes a week of work per report once the fields, filters, grouping and export format are known.
- Notifications. Email, SMS, push and in-app are four different implementations with four different costs. "The system notifies the user" specifies none of them.
- Search. Searching one field is trivial; searching across related records with ranking is a project of its own.
- Migration. Bringing existing data in is almost always harder than expected because the old data is inconsistent in ways nobody documented.
Naming these four explicitly in the spec, even briefly, moves them from assumption into scope.
A practical approach
A useful spec for a small project is usually five to fifteen pages: role list, workflow descriptions, data fields, integration list, non-functional numbers, acceptance criteria, and an explicit out-of-scope section.
That last section does more work than its length suggests. Writing "reporting beyond the three listed screens is out of scope for this phase" costs one line and removes an entire category of later disagreement.
Related Manboo Services
- Flutter App Development for iOS and Android MVPs.
- Business Software Development for CRM, booking, inventory and workflow systems.
- Admin Panel Development for operations dashboards and backend management.
- AI API Integration when your product is ready for smart search, chat or automation.
- Request a scope review and project estimate when you are ready to plan the first version.