How to Write a Software Development Brief [Template + Guide]

Of every factor that determines whether a software project succeeds — the technology stack, the agency you choose, the budget you allocate — the one that matters most arrives before any of those decisions are made. It is the quality of your brief.

We have reviewed hundreds of project enquiries at Cyberbeak. The single most reliable predictor of whether a project will land on time, on budget, and with the outcome the client actually wanted is not how large the company is, how technically sophisticated the stakeholders are, or even how much they are willing to spend. It is how clearly and honestly they have written down what they need and why.

A strong brief does not guarantee a successful project. But a weak brief almost always produces a failed one — or at minimum an expensive, drawn-out, frustrating one. It creates misaligned expectations from day one, produces wildly inaccurate quotes, invites the wrong agencies to compete, and sets the team up to build the wrong thing very efficiently.

This guide walks you through exactly how to write a brief that gets you accurate pricing, attracts serious partners, and gives your project the foundation it needs. We have included a practical fill-in-the-gaps template you can use today, along with the mistakes we see most often and how to avoid them.

---

Why a Good Brief Matters

When an agency receives a vague brief, they have two choices: ask you a lot of clarifying questions before they can scope the work, or build assumptions into their proposal and price for uncertainty. Most agencies do the second — partly because it is faster, partly because they do not want to appear demanding before they have won the business.

Pricing for uncertainty means padding. An agency that does not know your integration requirements will assume complexity. An agency that does not know your timeline constraints will add buffer. An agency that does not know whether you have design assets or need them built from scratch will quote for both possibilities and charge accordingly. The result is a proposal that is either inflated to cover the unknowns, or scoped so loosely that the budget expands the moment work begins.

The inverse is equally true. A clear, detailed brief produces accurate pricing, because the agency can scope precisely rather than defensively. It produces better proposals, because experienced teams can engage with your actual problem rather than making educated guesses. And it produces better shortlists, because agencies that are not a good fit self-select out rather than winning work they cannot deliver well.

Beyond pricing, a well-written brief does something more important: it forces you to clarify your own thinking. The act of writing down the problem you are solving, the users you are solving it for, and the commercial outcomes you are measuring against will surface gaps, contradictions, and assumptions in your thinking before they become expensive mid-project change requests. Many of our best-run projects started with a client who told us they had written and rewritten their brief three times before sending it — and each version had taught them something about their own product.

---

What a Software Brief Is NOT

Before we get into structure, it helps to be clear on what a brief is not — because conflating it with other documents is one of the most common mistakes we see.

A brief is not a technical specification. A technical specification describes exactly how a system will be built — the data models, the API contracts, the technology choices, the architecture decisions. That document comes later, usually as a joint output between you and the agency you hire, after a discovery phase. Writing a technical specification before you have engaged a development partner is putting the cart before the horse. It locks you into decisions that should be made collaboratively.

A brief is not a wireframe or a set of mockups. Wireframes are design artefacts that describe interface layout. Sharing them can be useful context, but a brief is not a collection of screens. Describing what the software should do at the level of user flows and outcomes is far more useful than describing what you think the interface should look like. The latter constrains the agency without solving the underlying problem.

A brief is not a contract. Nothing in a brief is legally binding. It is an invitation to engage — a structured description of your project designed to attract the right partners and enable them to respond accurately. Contracts come after selection, during the commercial phase. Treat the brief as a communication document, not a legal one.

A brief is not a request for the cheapest price. If your brief reads primarily as a negotiating document designed to solicit a low quote, experienced agencies will notice and either decline or build defensive assumptions into their pricing. The goal of a brief is shared understanding, not a race to the bottom.

With those distinctions clear, here is what a brief actually is: a structured, honest account of the problem you are trying to solve, the context in which you are solving it, what success looks like, and what constraints you are working within. That is it. It does not need to be long. It does not need to use technical language. It needs to be clear, specific, and honest.

---

The 8 Sections Every Software Brief Should Include

1. Project Overview

Start with the problem, not the solution. This is the section most briefs get wrong — they open with a description of what the client wants to build rather than why they want to build it. The distinction matters enormously.

"We want to build a mobile app with a dashboard, a booking module, and an admin panel" is a solution description. "Our field service team currently manages 200+ weekly appointments across three regional offices using spreadsheets and phone calls, and we are losing roughly 15% of bookings to scheduling errors and miscommunication" is a problem description. The second is dramatically more useful, because it tells an experienced development team what actually needs to be solved — which may or may not require exactly the solution you have imagined.

Your project overview should cover:

• The core problem or opportunity you are addressing
• Who currently experiences this problem and how they manage today
• Why now — what has changed, or what is driving this initiative at this point in time
• A brief description of the solution you are considering (keeping in mind this is a starting point, not a fixed requirement)
• The type of product you are building — web application, mobile app, internal tool, API platform, e-commerce system, or a combination

Keep this section to one or two paragraphs. Its job is to orient the agency quickly, not to tell the complete story.

2. Business Context and Goals

Software exists to serve commercial or organisational outcomes. An agency that understands your business goals can make better technical decisions, flag risks you have not anticipated, and prioritise features against what actually matters to your bottom line.

This section should cover:

• Your business model — are you building for customers, internal users, or both? Is this a revenue-generating product or a cost-reduction initiative?
• Commercial objectives — what does success look like in business terms? More transactions, lower operational cost, faster processing time, entering a new market?
• Measurable success metrics — how will you know in 12 months whether the project succeeded? Be specific. "Improved efficiency" is not a metric. "Reduce manual data entry time by 60%" is.
• Strategic importance — is this a core product or a supporting tool? Is this an MVP designed to test demand, or a production system replacing something that already exists?
• Stakeholder landscape — who internally cares about this project and how? A brief that mentions "the CEO is personally sponsoring this initiative" or "the CFO has approved budget on the condition that we hit a December launch" tells an agency a great deal about the dynamics they will be working within.

3. Users

The best software is built around a precise understanding of who will use it and what they need to accomplish. Generic user descriptions ("small business owners", "enterprise clients") are almost useless. Specific ones are extremely valuable.

For each user type, describe:

• Who they are — their role, their context, the environment in which they will use the product (office, mobile, field, high-pressure operations environment)
• Their technical sophistication — are they comfortable with complex software interfaces, or do they need a highly simplified experience? Do they use similar tools already?
• What they need to accomplish — the two or three jobs they need to be able to do efficiently using this product
• Volume — how many of these users are you designing for? Ten internal users have very different requirements to ten thousand consumers
• Any accessibility requirements — legal obligations or considerations for users with disabilities

If you have done user research, customer interviews, or have data on how users currently behave, share it. Even rough notes are valuable. If you have not done any user research, say so — a good agency will help you understand how to incorporate that into the discovery phase.

4. Core Features and Functionality

This is often the longest section of a brief, and it is worth investing time in getting it right. The goal is not to write a comprehensive feature list, but to communicate the scope of what you need clearly enough that an agency can estimate the work with reasonable confidence.

Structure this section around two categories:

Must-haves are the features without which the product cannot launch and deliver its core value. If removing a feature would mean the product fails to solve the problem it exists to solve, it is a must-have.

Nice-to-haves are features that would add value but are not required for launch. Being explicit about this distinction is one of the most useful things you can do in a brief. It tells the agency what is in scope for the initial engagement and signals that you understand scope management.

For each significant feature, write a brief user story in the format: "As a [user type], I want to [do something], so that [outcome]." User stories keep descriptions focused on user need rather than interface assumptions.

For example:

• As a field technician, I want to receive job assignments on my phone with all relevant client information attached, so that I do not need to call the office for details before arriving on site.
• As a finance manager, I want to export monthly transaction reports in CSV and PDF format, so that I can share them with our external accountants without manual reformatting.

You do not need a user story for every micro-interaction. Focus on the flows that define the product.

Also note any features you have explicitly decided are out of scope for this engagement. Stating what you are not building is sometimes as useful as stating what you are.

5. Technical Requirements and Constraints

This section is where many non-technical clients feel uncertain. Do not let that stop you from including what you know — and be honest about what you do not know, because a good agency will help you fill the gaps during discovery.

Cover the following as applicable:

• Existing systems and integrations — does this product need to connect to other software? List every system by name. CRM (Salesforce, HubSpot), ERP (SAP, NetSuite), payment gateways (Stripe, PayPal), communication platforms (Twilio), accounting software (Xero, QuickBooks), logistics APIs. Integration work is frequently the most significant source of unexpected complexity and cost, so the more specific you are here, the better.
• Data migration — are you moving data from an existing system? How much data, in what format, and how complex is it?
• Hosting and infrastructure preferences — do you have a cloud platform preference (AWS, Azure, Google Cloud)? An existing infrastructure you need to deploy within? Specific geographic data residency requirements?
• Technology constraints — does your internal team have a technology preference or requirement? Do you have developers who will maintain the product after launch, and if so, what is their technology stack?
• Compliance and regulatory requirements — GDPR, PCI-DSS for payment handling, HIPAA for healthcare data, ISO 27001, FCA regulations, accessibility standards (WCAG). List every compliance obligation you are aware of.
• Performance requirements — does the system need to handle large volumes of concurrent users? Real-time data processing? Sub-second response times under load?
• Browser and device requirements — which browsers and devices does the product need to support? Does it need to work offline?

6. Design and Brand

Be clear about where you are starting from so the agency can scope design work accurately.

• Existing brand assets — do you have a style guide, component library, or existing design system? If so, is the brief for new software that should follow these, or for a standalone product with its own visual identity?
• Existing design work — have you commissioned wireframes, mockups, or a UI design already? Are you expecting the agency to implement an existing design, or to design from scratch?
• Look, feel, and tone — describe the experience you want users to have. Reference examples of products you admire aesthetically or in terms of UX. If you have strong feelings about what you do not want, say so.
• Design deliverables expected — are you expecting the agency to produce design artefacts (style guide, component library, prototypes) as part of the engagement, or just implement the finished product?

7. Budget and Timeline

This is the section clients most frequently leave blank, and it is the most costly omission. We will address the budget question directly: refusing to share a budget does not protect you. It does the opposite.

When an agency does not know your budget, they cannot scope to it. They will either over-engineer (producing a proposal you cannot afford) or under-scope (producing a proposal that misses what you actually need). Either way, you waste time — yours and theirs — and end up with proposals that cannot be meaningfully compared.

You do not need to commit to a precise number. A range ("we have budget in the region of £60,000–£80,000 for the initial phase") is entirely sufficient and gives an agency everything they need to scope appropriately.

For timeline:

• Target launch date — if you have one, share it. If it is flexible, say so
• Hard deadlines — regulatory dates, product launch events, board commitments, contractual obligations
• Phased approach — are you open to phasing the build? If so, what does an MVP look like versus a full version?
• Internal availability — who from your team will be involved, and how much of their time is available? Client-side resource constraints are a legitimate input to timeline planning

8. Selection Criteria

Close your brief by telling agencies what you are evaluating them on. This is good practice for two reasons: it attracts agencies that genuinely fit your criteria and discourages those that do not, and it signals that you are a structured, professional buyer — which experienced agencies actively want to work with.

Common selection criteria include: relevant sector or technology experience, team seniority, communication approach, post-launch support model, pricing, cultural fit, and proposed approach or methodology. Weight them if you can — "technical capability is our primary criterion; price is secondary" is useful information.

---

Brief Template

Use this structure as a starting point. The example below shows a completed brief for a B2B trade marketplace — replace every field with your own project's details. Mark sections where you are uncertain so the agency can help you develop them during discovery.

---

TradeHub — B2B Marketplace Platform — Software Development Brief

Submitted by: Acme Distribution Ltd — Sarah Chen, Head of Product Date: 15 January 2025 Response deadline: 31 January 2025

---

Section 1: Project Overview

What is the core problem this software will solve? Who experiences it? Why is this being addressed now? What type of product are you building?

• Problem statement: Our network of 400+ trade suppliers currently manages buyer relationships through a mix of phone orders, email PDFs and a legacy order management system from 2011. Buyers — predominantly procurement managers at construction and facilities companies — cannot browse current stock, check real-time pricing, or place orders outside business hours. Suppliers have no visibility into buyer activity or order status without manual chasing.
• Why now: Two major competitors have launched digital procurement portals in the last 18 months. We are losing mid-market accounts specifically because we cannot offer a self-serve ordering experience. The board has approved the budget for Q1 2025.
• Proposed solution (high level): A multi-vendor B2B marketplace where approved trade suppliers list products and manage inventory, and verified trade buyers browse, request quotes, and place orders with net payment terms. Platform operator (us) manages supplier onboarding and earns commission on transactions.
• Product type: Web application (desktop-first, mobile-responsive)

---

Section 2: Business Context and Goals

What are the commercial or organisational outcomes this project is designed to deliver?

• Business model context: Platform commission of 4–8% on each transaction, tiered by supplier volume. Suppliers pay no listing fees. Buyers pay at net-30 or net-60 terms depending on account status.
• Primary commercial objective: Retain existing supplier network and recover 20% of lost mid-market buyer accounts within 12 months of launch.
• Success metrics: £2M GMV through platform within 6 months of launch; 80+ active suppliers listed within 90 days; average buyer session-to-order rate above 18%.
• Strategic importance: This is the company's primary digital growth initiative for 2025–2026. It is not a side project.
• Key internal stakeholders: CEO (final sign-off), Head of Product (day-to-day contact), Head of Commercial (supplier relationships), IT Manager (infrastructure decisions).

---

Section 3: Users

Who will use this product? Repeat for each distinct user type.

User type 1 — Trade Buyer (Procurement Manager)

• Role / description: Procurement managers and purchasing officers at construction, facilities management, and maintenance companies. They place repeat orders for consumables, tools, and equipment on behalf of their organisation.
• Technical sophistication: Medium — comfortable with web-based tools, use email and spreadsheets daily, but not technical
• Key jobs: Browse and search products across suppliers, check pricing and availability, place orders against existing accounts, track order status, generate purchase reports
• Approximate volume: 2,000–3,000 registered buyers at full rollout
• Accessibility requirements: WCAG 2.1 AA compliance required (some users are older trade professionals)

User type 2 — Trade Supplier (Vendor)

• Role / description: Sales and operations staff at our supplier network. They manage their product listings, respond to RFQs, and fulfil orders placed through the platform.
• Technical sophistication: Low to medium — many are not digitally sophisticated; the interface must be simple
• Key jobs: Upload and manage product listings and pricing, respond to buyer enquiries, manage order pipeline, view sales analytics, receive payouts
• Approximate volume: 400–600 registered suppliers

User type 3 — Platform Administrator (Internal)

• Role / description: Our internal operations team who approve supplier onboarding, manage buyer accounts, resolve disputes and monitor platform health
• Technical sophistication: High
• Key jobs: Approve/reject supplier applications, manage commission structures, view platform analytics, handle disputes

---

Section 4: Core Features and Functionality

Must-have features (without these, the product cannot launch):

Feature	User Story	Notes
Product catalogue and search	As a buyer, I want to search and filter products across all suppliers so I can find what I need quickly	Full-text search, filter by category, supplier, price, availability
RFQ (Request for Quote)	As a buyer, I want to request a custom quote from a supplier so I can negotiate pricing on large orders	Supplier receives notification and responds within the platform
Checkout with net terms	As a buyer, I want to place an order against my credit account so I can pay at net-30 without a card	Credit account limits set by platform admin per buyer
Seller product management	As a supplier, I want to add and update my product listings and pricing so my catalogue stays current	Bulk CSV upload required for suppliers with large catalogues
Order management (both sides)	As a supplier, I want to see incoming orders and mark them as dispatched so buyers get status updates	Email notifications at each status change
Commission and payout engine	As a platform operator, I want to automatically calculate commission on each transaction and schedule payouts to suppliers	Stripe Connect for split payments and payouts

Nice-to-have features (valuable but not required for launch):

Feature	User Story	Notes
Saved order lists / favourites	As a buyer, I want to save frequently ordered products so I can reorder quickly	Priority for V1.1
Supplier performance ratings	As a buyer, I want to see supplier fulfilment ratings so I can make informed decisions	Needs moderation policy before launch
ERP integration (Sage/Xero)	As a buyer, I want orders to sync to our accounting system automatically	Dependent on which ERPs buyers actually use — needs further research

Explicitly out of scope for this engagement:

• Native iOS or Android mobile apps (responsive web is sufficient for launch)
• Multi-currency or international shipping (UK market only at launch)
• Public-facing product pages for SEO (platform is closed to registered accounts only)

---

Section 5: Technical Requirements and Constraints

• Integrations required: Stripe Connect (split payments and supplier payouts), SendGrid (transactional email), HubSpot CRM (buyer and supplier records sync), Companies House API (KYB verification during supplier onboarding)
• Data migration: Yes — approximately 12,000 product records from legacy system (SQL Server database, export available as CSV). Supplier and buyer account data also needs migrating (~400 suppliers, ~1,800 buyer accounts). Data quality is known to be inconsistent and will need cleaning.
• Hosting / infrastructure preferences: AWS preferred (existing AWS account in place). UK region required for data residency.
• Technology constraints: No constraints on stack choice — we defer to the agency's recommendation. Legacy system is .NET but we are not tied to Microsoft technology.
• Compliance requirements: GDPR (UK) — we process personal data for both buyers and suppliers. No PCI-DSS scope required if we use Stripe for payment handling.
• Performance requirements: Product search must return results in under 1 second. Platform must support 500 concurrent users at launch without degradation.
• Browser / device support: Chrome, Firefox, Safari, Edge (latest 2 versions). Mobile-responsive but desktop is the primary use case.
• Known technical unknowns: We are not sure whether real-time inventory sync from supplier stock systems is feasible at launch — this depends on supplier system compatibility. We would like the agency's view on this during discovery.

---

Section 6: Design and Brand

• Existing brand assets: We have a basic brand style guide (logo, colour palette, typography) but no component library or UI design system
• Existing design work: None — we are starting from scratch on the product design
• Design approach: Agency to design from scratch, working within our brand guidelines
• Look and feel reference: We admire the clarity of Faire.com (wholesale marketplace) and the efficiency of Procore's project management interface. Clean, professional, functional over decorative.
• Design deliverables expected: UX wireframes for key flows, high-fidelity UI designs for all screens, a component library handed over with the codebase

---

Section 7: Budget and Timeline

• Budget range: £120,000–£180,000 for the MVP (Sections 1 and 4 must-haves above). We understand this may need to be refined after discovery.
• Target launch date: Private beta with 20 pilot suppliers and 50 buyers by October 2025. Public launch January 2026.
• Hard deadline: The private beta date (October 2025) is important but not contractually fixed. The January 2026 public launch is tied to a trade show appearance and is firm.
• Open to phasing: Yes — we are open to phasing the build if it reduces risk. Our preference is to have something usable by buyers and suppliers as early as possible, even if the feature set is reduced.
• Client-side resource availability: Sarah Chen (Head of Product) is available 2–3 days per week as the primary client contact. Our IT Manager can support on infrastructure decisions. No internal development resource.

---

Section 8: Selection Criteria

We will evaluate responses on the following criteria (in approximate order of priority):

1. Demonstrated experience with multi-vendor marketplace platforms and split payment / Stripe Connect implementations
2. Seniority of the team proposed for our project — we want senior engineers, not a junior delivery team
3. Credibility and specificity of the proposed technical approach (we will be put off by generic proposals)
4. Post-launch support model and what ongoing development retainer options look like
5. Commercial fit within our stated budget range

Response format requested: Please include a summary of your proposed technical approach, a rough cost estimate broken down by phase, your proposed team composition with seniority levels, and two or three case studies of comparable marketplace projects.

Response deadline: 31 January 2025

---

Common Brief Mistakes

Being too solution-focused

The single most common brief mistake is describing a specific interface rather than a user need. "We need a three-column dashboard with a filter panel on the left and a data table in the centre" tells an agency what you have imagined, not what your users need to accomplish. It constrains the design without solving the underlying problem, and it closes off solutions the agency might have proposed that are better than what you imagined.

Describe the outcome. Describe the user. Let the design process determine the interface.

The "Airbnb for X" brief

"We want to build an Airbnb for dog-walking" or "a Spotify for audiobooks" or "an Uber for garden maintenance" is not a brief. It is a metaphor. And it is almost always a sign that the writer has not yet done the hard work of understanding what the product actually needs to do.

Reference products are useful for conveying rough ambition or aesthetic direction, but they cannot substitute for a real description of your users, your features, and your business model. Experienced agencies have seen this pattern so many times that it has become a mild red flag — it suggests the client may not yet have clarity on what they are actually building.

Refusing to share your budget

We cover this above, but it deserves emphasis. When a client refuses to share a budget, experienced agencies do not assume it means the budget is large. They assume it means either the client does not know, the budget is smaller than the project requires, or the client is using budget opacity as a negotiating tactic. None of those assumptions produce better outcomes for you. Share a range. It will get you better proposals.

Omitting a timeline

No timeline information means an agency cannot plan resource allocation, flag scheduling conflicts, or tell you whether your ambitions are realistic. Even "we have no hard deadline but would ideally like to launch within six months" is useful. A complete absence of timeline information is not.

Missing integration requirements

Integrations are the most underestimated source of complexity and cost in software projects. A CRM integration that sounds trivial can involve complex authentication flows, rate limits, data mapping, error handling, and ongoing maintenance overhead. An agency that discovers an undisclosed integration mid-project will raise a change request. Share every integration requirement you are aware of, even if you are not sure of the technical details.

Sending the brief to too many agencies

A common misconception is that sending your brief to fifteen agencies maximises competition and drives down prices. In practice, it does the opposite. Experienced agencies know when they are in a large competitive process. They either decline to invest in a thorough response, or they produce a lower-effort proposal that covers the bases without offering any genuine insight. A shortlist of three to five agencies who are genuinely suited to your project will produce better, more engaged responses than a mass distribution that signals you are treating this as a procurement exercise.

---

How Long Should a Brief Be?

There is no universal answer, but there are sensible guidelines by project type.

Project Type	Suggested Brief Length
Simple internal tool or MVP	2–4 pages
Mid-complexity web application	4–8 pages
Consumer product or platform	6–10 pages
Enterprise system with multiple integrations	8–15 pages
Regulated industry (fintech, health, legal)	10–20 pages

Length is not a proxy for quality. A four-page brief that is precise, honest, and complete will produce better responses than a fifteen-page brief that is padded with vague requirements and repeated section headers. Focus on substance, not volume.

If your brief runs longer than ten pages for a simple project, it is usually a sign that requirements are not yet sufficiently prioritised, or that you are including design decisions and technical specifications that belong in later documents.

---

What Happens After You Send the Brief

What a good agency response looks like:

A strong response to your brief will demonstrate that the agency actually read it. It will reference your specific problem, your users, and your constraints — not just repeat your brief back to you with marketing language wrapped around it. It will ask clarifying questions where information is genuinely missing rather than assuming. It will give you a credible estimate with clear assumptions stated, and it will tell you what they are assuming in order to produce that estimate.

A good response will also push back constructively where appropriate. If your timeline is unrealistic for the scope you have described, a competent agency will tell you that, explain why, and propose options. If your budget is misaligned with your ambitions, they will say so clearly. Agencies that tell you everything is achievable within your constraints without any qualification are not being optimistic — they are either not looking closely enough, or they are planning to raise the issue later as a change request.

What a weak response looks like:

Beware of proposals that are heavy on company credentials and light on engagement with your actual brief. Beware of fixed-price quotes for complex projects with no stated assumptions — this either means the price includes large contingency, or the scope will be interpreted narrowly and expanded later. Beware of agencies that cannot tell you who will be working on your project and what their experience level is.

Running the process after responses arrive:

Once you have responses, run each through the same evaluation framework. Compare them on the criteria you stated in your brief. If any agency has made assumptions you did not intend, go back with clarifying questions before you discount them — sometimes assumptions reveal a genuine misreading that a conversation can resolve. Invite your two or three preferred agencies to a call. The quality of the conversation will tell you almost as much as the written proposal did.

---

How We Use Your Brief at Cyberbeak

When a brief lands in our inbox, the first thing we do is read it end to end without looking at any of the technical details. We want to understand the business problem and the commercial context before we think about technology. Briefs that make this clear are the ones we get most excited about — they tell us we are dealing with a client who thinks in outcomes, not just features.

From there, we assess fit. We are honest when a project is not in our wheelhouse, and we will say so rather than propose ourselves into a role we cannot fill well. If the project is a fit, we move into a structured response process — one person owns the commercial response, one owns the technical approach, and we review both together before anything goes to the client.

Before we finalise any proposal, we will usually come back to you with a short list of clarifying questions. These are not a sign that your brief was poor — almost every brief has gaps, and the gaps are usually where the most important decisions live. We would rather surface an ambiguity in a conversation than assume our way through it and discover the mismatch six weeks into development.

For larger or more complex projects, we often recommend a paid discovery phase before we commit to a full build estimate. Discovery lets both sides understand the problem deeply, validate assumptions with users, and produce a scope document that is grounded in evidence rather than guesswork. The output of a good discovery phase is not just a better scope — it is a significantly higher probability of a successful project.

---

FAQ

Do I need a brief if I am engaging on a time-and-materials basis?

Yes, though it can be shorter and less prescriptive. Even on T&M engagements, an agency needs to understand your business context, your users, your integration landscape, and your success criteria in order to make good decisions during development. A brief for a T&M engagement does not need to be an exhaustive feature list, but it should cover the first four sections of the template above as a minimum. Without that context, even an excellent development team will build the wrong thing efficiently.

Should I include wireframes or mockups in my brief?

Including existing wireframes or mockups as supplementary material is fine — it can help convey scope and intent, particularly for complex user interfaces. But do not mistake wireframes for a brief, and do not let the existence of wireframes replace a proper description of user needs and business goals. If your wireframes represent early thinking rather than validated design, label them as such. An agency that interprets rough wireframes as fixed requirements will price and build to those wireframes, even if they would have proposed something better with more freedom.

What if I genuinely do not know my budget?

Start with first principles. Research what comparable software products cost to build — our custom software development cost guide is a useful starting point. Talk to your finance team or board about what investment is justified given the commercial value the project is expected to deliver. Even a broad range — "we are thinking in the £40,000–£100,000 range depending on scope" — is more useful than silence. If you are truly at zero budget clarity, the most honest approach is to say so in your brief and ask agencies to respond with a range of scoping options at different investment levels.

How do I compare quotes from different agencies when they have scoped things differently?

This is one of the most common challenges in a competitive brief process, and the honest answer is that you cannot do it directly without asking clarifying questions. When quotes differ significantly, the most useful step is to identify the key assumptions each agency has made and ask them to align on a common scope before finalising their numbers. A cheap quote that has scoped out half the integration work is not cheaper — it is incomplete. A more expensive quote that includes a comprehensive testing phase, documentation, and post-launch support may represent better value. Ask each agency to break their quote down by phase or work stream, so you can compare like for like rather than comparing totals.

---

A well-written brief is an investment of a few hours that pays back many times over — in more accurate quotes, better proposals, a cleaner agency selection process, and a development engagement that starts from shared understanding rather than accumulated misassumptions.

If you would like a second opinion on a brief you have already written, or if you are building a project and would like to talk through how to structure your requirements, we would be glad to help. Get in touch with our team and we can typically turn around an initial response within one business day.