Ask three software companies for a price on the same idea and you may get three numbers that differ by a factor of four. Nobody is lying. Each team imagined a different project, because the idea you described could be read several ways, and each filled the gaps with its own assumptions.
The cure is not a longer meeting. It is a short written brief that closes the gaps before anyone prices anything. It takes an hour or two to write, it makes every quote more accurate and comparable, and it tells a good team that you are a client who will be easy to work with.
What a brief is, and what it is not
A brief is a description of the problem and the outcome, in your words, with the facts a team needs to estimate. It is not a technical specification, and you do not need to know which framework to use. If you can explain what happens in your business today and what should happen instead, you can write one.
It should fit on one to three pages. A twenty-page document is usually a sign that the decisions have not been made.
A template you can copy
Answer each section in a few lines. "I don't know yet" is a fine answer, as long as you say it.
1. The problem What is going wrong or missing today? Who feels it, and what does it cost (time, money, customers, mistakes)? Describe the problem, not the app.
2. The people who will use it List each kind of user (for example: receptionist, manager, customer, accountant), roughly how many of each, and what each needs to do. Mention who must not see what.
3. How it works today The steps as they happen now, including the spreadsheets, WhatsApp groups, paper forms and tools in the middle. Attach a photo of a form or a screenshot of a sheet if you have one. This is the most valuable section, and the one most often skipped.
4. What the system must do The five to ten most important workflows, one line each, in the form "a [person] can [do something] so that [result]". For example: "a receptionist can book a patient into a free slot so that no two patients share a room". Put them in order of importance.
5. Data and other systems Does it need to connect to an accounting program, a payment gateway, a website, a device, or an existing database? Do you have data to bring in, and in what shape (Excel, an old system)? Who owns the logins we would need?
6. Constraints
- The deadline, and why it is that date.
- A budget range. A range is enough, and it lets a team propose the right scope.
- Languages (Arabic, English, both), and whether it needs to work on phones.
- Rules you must follow: tax invoicing, data protection, industry regulation.
- Where it should be hosted, if you have a preference.
7. How you will know it worked Two or three results you can check: "invoices are issued in under a minute", "no double bookings", "the month-end report takes an hour, not two days".
8. Out of scope for now What you do not want in the first version. Saying no early is the cheapest way to control the price.
9. Risks and unknowns What worries you, what is not decided, who must approve what, and who makes the final decision for you.
10. Attachments Screens of systems you like or dislike, forms, reports, examples of your data, and your logo and brand files if relevant.
Mistakes that make quotes useless
- Describing a solution instead of a problem. "I want an app like X" gives a team a brand, not a requirement. What do you want people to be able to do?
- Hiding the budget. It feels like a negotiating tactic, but it makes teams guess. Give a range and ask what fits inside it, and what each extra costs.
- Skipping the current process. A new system that ignores how work really happens will be built to a fantasy, and then fought by the people who use it.
- No named decision-maker. If five people can each change the requirements, the project never finishes.
- Treating everything as equally important. If all fifty features are "must have", the team cannot propose a first release.
How to compare the quotes you get
Do not start with the number. Read the rest first.
| Look for | Why it matters |
|---|---|
| A scope that matches your brief, point by point | Different quotes may be pricing different projects |
| Written assumptions | A cheap quote often hides assumptions that become extra charges |
| Who does the work | Senior people, or a junior team behind a senior name? |
| A way of working | Stages, demos and approvals, and how changes are handled |
| What is delivered, and when | A plan with dates that you can hold them to |
| Who owns the code, designs and accounts | You should own what you paid for, and hold the hosting accounts |
| Maintenance and support after launch | What is included, for how long, and what it costs |
| What is excluded | Hosting, third-party fees, content, training, data migration |
If two quotes differ a lot, ask each team to explain the difference, in writing. The answers tell you more about the teams than the numbers do.
When the brief is not enough
Some projects are too uncertain to price at once. In that case, good teams will propose a paid discovery phase: one to a few weeks of interviews, process mapping and rough designs that ends in a written plan, a scope and a firm estimate. It costs money, and it usually saves more than it costs, because the expensive surprises appear while the project is still on paper.
A short checklist before you send it
- One to three pages, in plain language.
- The problem and the outcome come before any feature.
- Users, roles and who must not see what are listed.
- The current process is described, with an attachment.
- The ten most important workflows are ranked.
- Integrations, existing data and constraints are named.
- There is a budget range and a reason for the deadline.
- Success is measurable, and what is out of scope is stated.
- One person is named as the decision-maker.
A good brief turns the first conversation with a software team from "what do you want?" into "is this the right plan?", and that is where good projects start. If you have a brief, or only the beginnings of one, send it to us. A senior engineer reads every message, and we will tell you plainly what we would do first.
