# Fixed scope, fixed price: how to size a software build before you sign
A software build can be quoted at a fixed price once six things exist in writing: the screen list, the integrations, the user roles, the state of the data you already hold, what counts as finished, and what is deliberately excluded. Miss one of them and you get one of two numbers. Either a padded quote with insurance baked in, or a cheap quote that grows through change requests until it passes the padded one. Our own fixed-scope work starts at AED 9,000 for an internal tool or prototype in about two weeks, and AED 18,000 for an MVP, and the reason we can publish those numbers is that we refuse to quote until the six items are on a page.
Most buyers in Dubai never get to that page. They send an enquiry, get a form, get a discovery call, and get told the answer depends on requirements. That answer is half true, and the useful half of it is never explained.
Why the price sits behind a form
Two separate things drive that form, and only one of them is dishonest.
The honest driver: a developer who quotes a number against an undefined thing is betting his own money. If you ask for "a booking system" and he says AED 30,000, he has silently guessed at whether you want payments, whether the calendar syncs both ways, whether staff can override a slot, whether it needs Arabic, and whether your existing 4,000 customer records come along. Any one of those guesses can double the work. So he either quotes high enough to survive being wrong, or he refuses to quote at all until you talk.
The dishonest driver: the form is a lead capture. A quoted range on a public page lets you compare and leave. A discovery call lets a salesperson anchor you. This is why a mid-market business application in Dubai gets advertised at AED 92,000 to 294,000 over two to five months, with the real number produced only after someone has spent an hour building rapport with you. The range is real for that class of project. The sequencing is a sales technique.
The part of "it depends on requirements" that is genuinely true: the total depends on requirements. The part that is false: the method of pricing does not. A competent developer can tell you, in one conversation, which parts of your project are fixed-priceable today and which parts are not, and why. If nobody will tell you that, you are talking to a salesperson rather than the person who will build it.
What has to be nailed down before a fixed price is possible
This is the working list. Bring it filled in and you change the conversation from "we'll get back to you with an estimate" to a number.
A screen list, counted
Not a description of the product. A list of the actual screens or steps, each with a one-line purpose. "Login. Customer list. Customer detail with booking history. New booking form. Payment status view. Admin settings." Six items. A developer reads that and immediately knows the size of the shell.
Sketch them on paper if you like. Fidelity does not matter, the count does. Every project I have seen go badly started with a screen list that was implied rather than written, and it turned out the buyer had four screens in mind while the developer had eleven.
Integrations, named, with their access status
"It connects to our CRM" is not a scope item. "It writes a deal into HubSpot when the payment succeeds, and we already have an admin account and API access" is a scope item.
For most builds in this market the list is short and predictable: a CRM, WhatsApp, a payment gateway, sometimes an accounting tool, sometimes a spreadsheet that nobody wants to admit is load bearing. What changes the price is not the number of connections, it is whether each one has documented access that you can hand over on day one. A gateway where your account is already live and approved is a day of work. The same gateway where approval is still pending is an unknown, because the sandbox rarely behaves like production.
Roles, not "users"
Ask who touches the thing and what each of them must never see. Two roles is cheap. Five roles with overlapping permissions is a different product, because every screen now needs to be built and tested more than once.
Write it as sentences: "A sales agent sees only her own leads. A manager sees the whole team and can reassign. Finance sees amounts but not phone numbers." That paragraph is worth more to an estimator than a twenty page brief.
The data you already have, in the state it is actually in
Say the true numbers. 12,000 contacts, spread across two spreadsheets and one old CRM, with duplicates, with phone numbers stored in four different formats, and roughly a third of them missing a source tag. That sentence is uncomfortable to write and it is the single most valuable line in your brief, because messy data is the classic source of the invoice that arrives after the fixed price.
If you do not know the state of your data, that is fine, but say so. It becomes a separate, priced piece of work instead of a hidden cost inside the build.
What "done" means, as tests someone can run
Acceptance criteria in plain language. "A new WhatsApp enquiry appears in the CRM within 60 seconds with the phone number and the ad source attached. A staff member can issue a payment link from the deal card. When the payment clears, the deal moves to Paid and the customer gets a confirmation."
Three or four sentences like that are enforceable. "It should work smoothly" is not, and the reason projects end in argument is almost always that nobody agreed what finished looked like before the money moved.
The exclusion list
The most underrated document in software procurement. A written list of what is not in the build. No native mobile app, web only. No Arabic in version one. No migration of historical bookings before January. No integration with the accounting tool yet. No custom reporting beyond the two views listed.
Buyers resist writing this because it reads like giving something up. It is the opposite. A written exclusion list is what stops a contractor from quietly absorbing work he never priced, going quiet, and then delivering late. It also stops the argument where you say something was obviously included and he says it obviously was not. Both of you are protected by the same page.
Where fixed price honestly breaks
There are three situations where a contractor who insists on a fixed price is either padding the number or planning to fight you later.
An undocumented or unfamiliar third-party system. Some local portals, aggregator dashboards and older payment setups have integration behaviour that is not in any public documentation. Nobody can price the unknown responsibly. The correct move is a short, paid spike: one or two days, the deliverable being a written answer about whether and how the connection works.
Migration of dirty data. Cleaning and mapping records is priceable only after somebody has looked at an actual export. Ask for a fixed price on the build and a separate hourly block, with a cap, on the migration.
"We haven't decided how it works yet." If the commission logic, the approval chain or the pricing rules are still being argued about internally, no scope document exists to price. Paying a developer to build while you decide is how a fixed price becomes a time and materials project with extra paperwork.
For all three, the professional answer is a paid discovery step whose output is the scope document itself, priced and delivered separately from the build. We run that as a Growth Audit from AED 3,000, and the deliverable is the thing you can take to any developer, including one who is not us.
How to read the quote you get back
Two estimating methods show up in this market, and they tell you different things.
Per-screen pricing lists a line item for each screen, each with a price. It looks precise and reads well in a proposal. On a small build the precision is mostly theatre, because the real effort is rarely in the screens. It is in the wiring between them: the states, the failure cases, the retries when an external service times out, the question of what happens when a payment succeeds but the callback never arrives. Two projects with an identical screen count can differ by a factor of three in effort. Per-screen pricing also creates a bad incentive during delivery, where both sides argue about whether something is a new screen instead of whether it works.
Team-week pricing says "this is three weeks of two people". For a small project it is usually the more honest number, because it prices what actually consumes cost, and it makes the assumptions visible. Ask for the assumption list that sits under the weeks. If a developer cannot produce one, the weeks were guessed.
Then run a padding check. Take the team-week math at a plausible local rate and compare it with the fixed number you were given. A modest gap is normal and correct: the contractor is carrying the risk of being wrong, and that risk has a price. A gap of two or three times means you are buying insurance against a scope nobody bothered to define, and the fix is to define the scope rather than to negotiate the number down.
One more question, and it is the fastest tell in the whole process: what happens if it finishes early? A contractor who says the price stands is pricing the outcome, which is what fixed price means. One who becomes uncomfortable was pricing the hours all along.
Change requests, and the boundary that makes them fair
A change request is any change to the four lists: screens, integrations, roles, or acceptance criteria. Everything else is delivery, and delivery is already paid for. Moving a button, fixing something that does not match the agreed criteria, adjusting wording, changing a colour: none of that is a change request, and a contractor who bills for it is mining the contract.
The mechanics should be boring. Numbered item, one paragraph describing the change, a price, a note on schedule impact, agreed by email before anyone writes code. Email is enough. What matters is that the change is priced before the work rather than discovered on the final invoice.
On our own builds the boundary is published: fixed scope, fixed price, handover, then two weeks of revisions included. Inside that window, anything that fails the agreed acceptance criteria is ours to fix. A new screen or a new integration is a new line, quoted before we start it. Nobody has to interpret anything.
What we actually do, with the numbers on the page
I run slgo.ai out of Dubai. We build fixed-scope software and then operate it, which is a different position from selling hours.
An internal tool or working prototype starts at AED 9,000 and takes about two weeks. An MVP with real users starts at AED 18,000. Both at fixed scope and fixed price, with every line the AI writes reviewed by a human engineer before it touches customer data or a payment. If the answer turns out to be automation rather than software, one process is AED 6,000 to set up and AED 1,200 a month to run. Budget separately for maintenance at 15 to 25 percent of build price per year, plus hosting from around AED 8,000 a year, and treat any quote that stops at the build number as incomplete.
Those prices are public because we scope before we quote, not because we are cheap. The same discipline runs our own operation: the studio side of the group takes bookings, quotes, payment links and CRM updates through an automated loop we built for ourselves, producing around AED 67,600 net a month at roughly 5x return on ad spend. We fixed the scope on that build too, and it shipped in two weeks.
Bring this to the first call and get a number in one conversation
Ten items. None of them require a technical background.
- The screen list, counted, one line of purpose each.
- Every tool it must talk to, with a yes or no on whether you already have admin access.
- One real end-to-end example of the process today, with actual names and amounts, from first contact to money received.
- Volumes: enquiries a month, active customers, records to migrate.
- Who uses it, by role, and what each role must not see.
- Three sentences describing what "working" looks like, phrased as things someone can test.
- Your exclusion list, even a rough one.
- An export of your existing data, or an honest description of its condition.
- The date that matters and why it matters, if there is one.
- Your ceiling. Not to be negotiated against, but so a serious contractor can tell you in minute five whether your scope fits your budget instead of in week three.
A developer who cannot turn that into a fixed number, or into a clear statement of which one piece needs a paid discovery step first, is telling you something useful about how the project would have gone. If you want the scope document produced independently before you commit to anyone, that is what the audit exists for, and it is yours to shop around with.
