Short answer: Scope a software project by writing a one-page brief that covers six things: the workflows, the people and approvals, the systems to connect, the data to bring in, the languages and devices, and who runs it after launch. With that page, vendors can price the same thing and you can compare their answers. A rough page is enough to begin.
Why do vague briefs produce quotes you cannot compare?
Imagine asking three vendors for "a system to manage our projects". One quotes a simple tracker. One quotes a platform with approvals and reporting. One quotes something in between. All three are honest, and none of them can be compared with the others, because each has filled the gaps with its own guesses.
A written scope removes the guesses. It does not need to be technical. It needs to describe your work.
What goes into the one-page brief?
Six headings are enough. Our scoping checklist lays them out as a template you can fill in.
1. Workflows
Describe each path work takes from start to finish: a purchase request, a site inspection, a tenant maintenance request, a customer booking. Say who starts it, who finishes it and what goes wrong today. Two or three workflows are plenty for a first release.
2. People, roles and approvals
List who uses the system and what each role can do. Note the approvals that matter, such as "the commercial manager approves above a threshold". Cost follows the number of roles and rules more closely than the number of screens.
3. Systems to connect
Name the accounting system, ERP, HR tool or portal the new system must talk to. Say whether you can get documentation and access. An integration with a well-documented system costs far less than one with an old system that only exports files.
4. Data to bring in
Say what exists today and where: spreadsheets, a database, paper. Moving old data is real work, and it is often forgotten.
5. Languages, devices and places
Will staff or customers use Arabic, English or both? Do people work on phones, on site, offline for part of the day? Several sites or entities change the design.
6. Hosting and who runs it
Say whether you want the vendor to host and support the system, host it in your own cloud account, or hand it to your team. Mention any data residency requirement. Our guide to where UAE business data lives explains the options.
What should you bring to a discovery call?
Bring less than you think. Useful items are:
- The one-page brief, even if rough.
- A sample of the documents or screens people use today, with sensitive detail removed.
- The names and roles of the two or three people who will use it daily.
- A list of the systems it must connect to.
- Anything you already know you do not want.
We do not need a detailed specification. A plain description of the workflow, the people in it and the problem is enough to begin.
How should you compare quotes once you have them?
| Check | What to look for |
|---|---|
| Scope | Does each quote name the workflows, roles and integrations from your brief? |
| Phases | Is the work split into modules, so you can stop or change direction? |
| Design stage | Is the design written down before building starts? |
| Ownership | Do you own the source code of the custom work? |
| After launch | Who hosts, monitors and supports the system, and on what terms? |
| Change | How is a change scoped, priced and approved? |
If a quote cannot answer these, ask. Our guide to choosing a vendor gives the longer checklist, and what drives the cost of custom software explains why two systems with the same name can differ so much.
What do vendors need that buyers often forget?
Three things come up repeatedly. First, a named person who can answer questions about the workflow within a reasonable time. Second, access to the systems and documents the build depends on. Third, a decision about who approves each stage. Projects slow down on the client side far more often than on the engineering side, and the usual cause is a missing decision, not missing effort. This is the author's view from our own projects.
FAQ
How detailed should the brief be?
One page. If you need more, you are probably describing the design, which comes later in a written scope. See our method.
Can I scope a project without knowing the technology?
Yes. Describe the work, not the technology. A good vendor chooses the technology and explains the choice.
Should I share my budget?
It helps to share a range of what you are comfortable with, because it lets a vendor propose a first module that fits. It is your choice. We do not publish a price list, because price follows scope.
What if my workflows are not fully clear yet?
Say so. Unclear workflows are a reason to start with a short design stage, not a reason to wait. Our method starts there.
Do you work from a brief like this?
Yes. After a free 30-minute call, we send a written proposal with scope, timeline and price, phase by phase, before you commit.
Ready to write yours?
Download or fill in the scoping checklist, then book a free 30-minute discovery call.
