How to brief a software project so the quote means something

Describe what goes wrong today and what “better” looks like, in business terms: orders lost, hours spent, errors made, customers waiting. A team that understands the problem will often suggest a simpler solution than the one you had in mind.

These seven headings are enough for a first, meaningful estimate:

1. The problem today, and what it costs you.
2. Who will use the software — staff roles, customers, suppliers — and roughly how many of each.
3. The three to five jobs it must do on day one.
4. What it must connect to: accounting, ERP, payments, government systems, existing apps.
5. Where it will be used: office desktops, phones in the field, a counter, offline locations.
6. Language and local rules: Arabic and English, VAT, document formats, data location.
7. Timing and budget range — even a rough one.

Attach the spreadsheet you use today, a sample invoice, a photo of the paper form, a screenshot of the system you are replacing. Real material removes more ambiguity than any paragraph, and it shows the messy cases a description glosses over.

Do not specify the technology unless you have a reason (an existing team, a platform you are committed to). Do not design every screen. And do not list every feature you might want in three years — mark them as “later” so they shape the design without inflating the first quote.

A team that replies with a price and no questions has not understood the work. The useful first response is a list of questions, assumptions and a suggested first release. That conversation is where an estimate becomes something you can rely on.