Estimates vary widely when teams are guessing at what you need. A short, structured brief reduces that guesswork. It does not need to be a technical specification — it needs to describe the problem clearly enough that a team can ask good follow-up questions.
1. Describe who will use it
List each type of user and what they need to accomplish. “Office staff approve orders” and “customers check delivery status” are far more useful than “an admin panel and a customer area”.
- Roles: who signs in, and what should each role be able to see or change?
- Volume: roughly how many people in each role, now and in a year?
- Context: desktop at a desk, or mobile on site?
2. Walk through the main workflows
Pick the three to five most important journeys and describe them step by step, including what happens when something goes wrong. Workflows reveal business rules — approvals, notifications, deadlines — that drive most of the build effort.
3. List the data and where it lives today
Note the records the system must hold (customers, orders, jobs, invoices) and where that data currently sits. If it needs to move from spreadsheets or another system, say so early: migration is often underestimated.
4. Name the integrations
Payment providers, accounting tools, email services, maps, existing internal APIs — each integration adds work and risk. A simple list with links to the providers is enough at this stage.
5. State your constraints
- Timeline, and whether a date is fixed or flexible
- Budget range, even if approximate
- Hosting, compliance or data-residency requirements
- Who on your side can make decisions and review work
6. Separate the first release from the wish list
Mark which features must exist on day one and which can follow. A smaller first release reaches real users sooner and gives you evidence for what to build next.
With these six points written down, you can compare proposals on substance rather than on guesses — and the conversations themselves become far more productive.