It does not need to describe every technical decision. It should give a developer enough information to identify the work, ask relevant questions and explain the assumptions behind an estimate.
A request such as “build a booking feature” leaves substantial room for interpretation. Does it need payments, staff approval, calendar synchronisation or cancellation rules?
This guide shows how to turn a broad request into a clearer development brief, with a worked example and a template you can use.
What Makes a Brief Estimable?
An estimable brief gives the developer a reasonable boundary around the work.
It explains:
Some questions may remain unanswered. Record them clearly so the developer can distinguish defined work from work that needs investigation.
An estimate is more useful when its assumptions are visible.
Start With One Outcome
Describe the result your business wants from the work.
“Allow existing customers to request an appointment through their account, with staff confirming or rejecting each request.”
This establishes more than “add online booking.”
It identifies the users, where the feature sits and the fact that a submitted request is not automatically a confirmed appointment.
Keep the outcome specific enough to guide the first delivery.
For broader product planning, our MVP development page explains how to define a focused first release.
Identify the Users and Their Permissions
List the roles involved and what each should be able to do.
For the appointment example:
| Role | Required actions | Access boundary |
|---|---|---|
| Customer | Submit a request and view its status | Own requests only |
| Staff member | Review and respond to requests | Assigned records |
| Administrator | Manage staff access and service settings | Agreed administrative functions |
Do not assume that an administrator needs unrestricted access to every part of the system. Define the permissions your business requires.
If several people from the same customer organisation need access, explain how their accounts relate to one another.
These decisions affect the interface, backend logic and testing.
Describe the Main Workflow in Order
Write the process as a sequence of observable actions.
For example:
- 1The customer signs in.
- 2They choose a service.
- 3They submit a preferred date and time.
- 4The application records a pending request.
- 5A staff member receives a notification.
- 6Staff confirm or reject the request.
- 7The customer sees the updated status.
Then explain what each important status means.
Does “confirmed” reserve an appointment in another system? Can a customer change a pending request? Does rejecting it require a reason?
A short workflow with clear rules is easier to estimate than a long list of disconnected features.
Add the Rules That Change the Work
Business rules often account for effort that is missing from an initial enquiry.
For a booking request, clarify:
- How far ahead a customer can request an appointment.
- Which time zone applies.
- Whether customers can have several pending requests.
- Who can approve a request.
- Whether a confirmed booking can be changed.
- Whether payment is required.
- Whether staff approval must happen before another system is updated.
Separate current rules from future ideas.
If a decision is unresolved, record the question and identify who can answer it.
Include Important Exceptions
The main workflow describes what happens when everything goes as expected.
The brief should also identify failures that matter to the business.
Examples include:
- A customer submits twice.
- Required information is missing.
- A user tries to access another customer’s record.
- The notification service is unavailable.
- A staff member loses access.
- A connected calendar rejects an update.
You do not need to prescribe the code used to handle each situation. Explain the expected business behaviour.
“If the notification cannot be sent, keep the booking request and make the failed notification visible to authorised staff.”
That requirement is more useful than “handle errors.”
Explain What Already Exists
Tell the developer which parts of the feature can rely on existing functionality.
Useful information includes:
Avoid assuming that something can be reused simply because it appears on screen. The developer may need to review the implementation.
Where the codebase is unfamiliar, a scoped application technical assessment can help establish what is available.
Name the Integrations
“Connect to our CRM” needs more detail before it can be estimated responsibly.
Include:
- The platform name.
- The information exchanged.
- Which system maintains the original record.
- What triggers the transfer.
- Available documentation.
- Test-account availability.
- The expected result when the transfer fails.
“When staff confirm a request, create an appointment in the connected calendar. Store the calendar reference against the request so later changes can be matched to the correct appointment.”
The exact implementation depends on the provider’s capabilities.
Explore our API development and integration service for connected-system requirements.
Write Acceptance Criteria You Can Check
Acceptance criteria describe the behaviour that must be demonstrated before the work is accepted.
Avoid vague statements such as:
Replace them with specific checks appropriate to the requirement:
| Vague requirement | More useful acceptance criterion |
|---|---|
| Customers can book | A signed-in customer can submit a request for an available service |
| Permissions work | A customer cannot retrieve another customer’s request |
| Staff can manage bookings | Authorised staff can confirm or reject a pending request |
| Notifications work | A status change triggers the agreed notification and records its result |
| Mobile-friendly | The agreed workflow can be completed on the specified mobile test sizes |
Some qualities need separate assessment methods. For example, a security review or accessibility evaluation requires a defined scope rather than a broad acceptance statement.
State What Is Not Included
Exclusions help establish the boundary of the estimate.
For the booking-request example, the first scope might exclude:
- Online payment.
- Automated reminders.
- Recurring appointments.
- A separate mobile application.
- Historical data migration.
- Several calendar providers.
- Customer cancellation after confirmation.
These are illustrative exclusions. Your actual scope should reflect the business requirement.
An exclusion does not mean the feature can never be added. It means it is outside the work currently being estimated.
Read our guide to Prioritise the first development scope to select essential functionality around a testable user journey.
Separate Requirements From Design Preferences
Both matter, but they answer different questions.
“The customer can see the status of each request.”
“Show pending requests above completed requests, using the approved status labels.”
Attach designs where available and identify which details are approved.
If designs are incomplete, clarify whether design work belongs in the estimate. The same applies to copy, images and other content.
For a customer account experience, see our customer portal development service.
Include Delivery Constraints
Tell the developer about conditions that affect the work.
These may include:
- A fixed event or launch dependency.
- Required working-hour overlap.
- Limited access to a test environment.
- A third-party supplier who must approve changes.
- Content arriving on a later date.
- Restrictions on production releases.
- A budget ceiling for the first stage.
Explain why a deadline exists. A preferred date and an immovable operational dependency need different planning.
Our developer hiring process explains how requirements connect to selection and onboarding.
A Developer Brief Template
Use the following structure for a feature or defined piece of development.
What to Ask for With the Estimate
A useful estimate should explain its basis.
Ask the developer to identify:
- Work included.
- Expected effort or project fee.
- Assumptions.
- Dependencies on your team or another supplier.
- Questions requiring investigation.
- Testing and deployment responsibilities.
- Circumstances that would require re-estimation.
You can also ask for the work to be broken into stages where that makes review easier.
Read our developer cost guide for comparing the complete cost of an engagement.
When the Brief Is Not Ready for a Build Estimate
Sometimes the next step is investigation.
Examples include an application that cannot be run, an undocumented integration or a feature whose required behaviour has not been decided.
In that situation, agree on a smaller discovery task with defined questions and outputs.
The result should help make the implementation scope clearer. It should not hide uncertainty behind an apparently precise number.
Discuss Your Developer Brief
DOT IT Services helps businesses turn software requirements into clear, estimable projects.
Tell us what you want to build and which parts of the brief are ready.
Written by DOT IT Services.