Why most briefs lead to bad estimates
Agencies estimate from what they read. A brief that lists screens without saying what people do on them invites guesses. A brief that describes the vision in big words but skips the boring parts, such as roles, payments and admin, hides a third of the work. The result is a low first quote and a long list of change requests later.
What a useful brief contains
- The problem: one paragraph on who has it and what they do today instead
- The users: each type of user and what they need to accomplish
- The core workflow: the steps a user takes from first visit to the result they came for
- Features: a list, each with one sentence on the simple version you need now
- Platforms: web, iPhone, Android, or all three
- Integrations: every external system the product must connect to, named
- Data: what you store, what is sensitive and where it must stay
- Constraints: deadline, budget band, required technologies, compliance needs
- What is out of scope for the first release
Describe features by outcome instead of by screen
"A dashboard" can mean a single table or a configurable analytics tool. Write what the user needs to learn or do. For example: the account owner sees revenue per month for the last year and can export it to a spreadsheet. That sentence tells an estimator the feature is a dashboard with charts and an export, roughly 48 to 104 hours in our model, instead of an open question.
Name the boring parts
These are the features most often forgotten in briefs, and together they can double the cost of a small product:
- Who can log in, and whether companies need team accounts with roles
- How customers pay: one time, subscriptions, invoices
- What your team needs in an admin panel to support customers
- Which emails the system sends, and when
- What happens when something fails, such as a payment or an upload
What to leave out
- Visual preferences beyond a few reference products. Design is a stage of its own.
- Technology choices, unless you have a team or a policy that requires them.
- Detailed wireframes for every screen, unless you already have them.
- Long market analysis. One paragraph on the problem is enough for an estimate.
Attach what you already have
Links to a current product, a clickable prototype, competitor screens you like, a spreadsheet you use today or a short screen recording of your current process are all worth more than extra pages of text. If you already have finished designs, say so: in our model that removes the 20 percent design overhead.
A brief outline you can copy
- Product in one sentence
- Who it is for, and the problem in one paragraph
- User types and what each must accomplish
- Core workflow in 5 to 10 steps
- Feature list, each with the simple version for launch
- Platforms and integrations
- Data and compliance notes
- Deadline and budget band
- Out of scope for version one
- Links and files
How the brief maps to our estimate form
Our estimate form asks for the same things in a structured way: the project type, the features from a fixed list, platforms, integrations, deadline, budget band and links. That is why it can show a price range in about a minute. Fill in the form first, then use the result to tighten your written brief. When you are ready, Discovery turns both into a full scope with fixed stage prices. You can read how that works in how to hire a software development company, and how prices are built on cost to develop an app.