What a fixed-price software scope actually contains
A fixed price is only as trustworthy as the document under it. Here is what belongs in a real software scope — and the questions to ask before you sign one.
Two suppliers quote the same project and land on the same number. One of them will deliver what you pictured; the other will deliver something adjacent to it and be entirely within their rights. The price was never the difference. The document under the price was.
A fixed price is a promise about a defined thing. If the thing is not defined, the price is just a number that will be renegotiated later — usually at the worst possible moment, when you have already paid a deposit and told your team a date.
Why a price without a scope is not an offer
Ask three vendors for "an e-commerce site" and you will get three prices covering three different projects. One assumed a catalogue of thirty products; one assumed thirty thousand. One assumed you would write the product descriptions; one assumed they would. None of them lied. The request simply did not contain enough information to be answered, so each supplier answered a slightly different question.
This is why the first deliverable of a serious engagement is not code. It is a document that makes the project small enough to price honestly.
The seven things a real scope names
- The problem, in plain language. One paragraph describing what is broken today and what "fixed" looks like. If the supplier cannot write this back to you in your own words, they did not understand the brief.
- Deliverables, as a countable list. Not "an admin panel" but the screens in it: products, orders, customers, reports, users and roles. Countable items are what make a timeline real.
- What is explicitly out. The most valuable paragraph in the document. More on this below.
- Data and migration. Where today's data lives, who exports it, in what format, and who is responsible when it turns out to be messier than expected — because it always is.
- Integrations, each named with an owner. "Payments" is not an integration. "QI Card, using credentials the client provides by week two" is. Every external system has a second party, and that party has their own timeline.
- Acceptance criteria. How both sides will agree the thing is done. Usually a short list of things that must be demonstrably true on a real environment.
- Timeline, price and payment schedule. Milestones tied to deliverables rather than to dates alone, so a delay on your side and a delay on theirs are told apart.
The boundary is worth more than the feature list
Most disputes are not about work that was done badly. They are about work that one side assumed was included. A scope that lists twenty deliverables and no exclusions is only half written.
Good exclusions are specific and unemotional: content writing and product photography are the client's; a native mobile app is not part of this phase; multi-currency pricing is not included; hosting is quoted separately. Nobody is offended by an exclusion read before signing. Everybody is offended by one discovered in month three.
| A line that will cost you | The same line, scoped |
|---|---|
| "Modern, responsive design" | "Five page templates, designed once, revised twice, at mobile and desktop widths" |
| "SEO included" | "Titles, descriptions, sitemap, structured data and clean URLs at launch — no ongoing campaign" |
| "Admin panel" | "Six admin screens, listed, with two roles: manager and staff" |
| "Bilingual" | "Arabic and English for interface and content, right-to-left layout, client supplies Arabic copy" |
| "Support after launch" | "Thirty days of defect fixes; changes after go-live are quoted separately" |
Change requests should be priced, not refused
Requirements change. Any process pretending otherwise breaks on contact with a real business. What a scope should define is not whether changes are allowed but how they are handled: a written request, an estimate in hours or a fixed add-on price, and your approval before work starts.
Two failure modes to watch for. A supplier who says yes to everything without repricing is quietly building a reason to be late, and the bill arrives as a surprise anyway. A supplier who treats every question as a change request is protecting a thin scope. The healthy middle is a document precise enough that both of you can tell the difference between a clarification and a new feature.
Who owns what on the last day
This is the section people skip and later regret. Before signing, the scope should say plainly who holds the domain registration, the hosting account, the source code, the app store listings and the third-party accounts created for the project.
The pattern we see most often in Iraq is not malice, it is drift: a domain registered on a freelancer's personal account, a hosting login nobody has, an app published under an agency's developer account. Years later the business is still operating fine — right up to the day it needs to move, and discovers that the asset it paid for is not in its name. A scope that names the owner of every account costs nothing to write and prevents that entirely.
Nine questions to ask before you sign
- Can you describe the problem back to me in your own words?
- What is explicitly not included in this price?
- Which deliverables can I see working before final payment?
- Who supplies content, images and translations?
- What do you need from me, and by when, for the timeline to hold?
- How is a change request priced and approved?
- Whose name is on the domain, the hosting and the app listings?
- What happens in the thirty days after launch, and what does it cost after that?
- If we part ways, what exactly do I walk away with?
A supplier who answers these easily has done the work before. One who deflects is telling you something useful for free.
How we do it
Every software project we take on starts with a written scope: deliverables, timeline and price, before any commitment. Then short iterations on a real environment you can click from week one — because "working software you can try" is the only progress report that cannot be exaggerated.
The platform behind Iraq's leading serviced-office provider was scoped that way before a line was written: six branches, contracts, billing, bookings and meeting-room doors, delivered in phases and still operated for them today. The scope is what made a project that size predictable — not optimism, and not a bigger deposit.
If you are holding two quotes and cannot tell them apart, that is not indecision. It means neither document is finished yet.