--- title: How to Audit a Brief Before Handing It to a Developer or Agency description: Learn how to audit a project brief before handing it to a developer or agency, covering assumptions, scope, intent and how to define success clearly. image: https://weareaffective.com/hubfs/learning-centre-images/how-to-audit-a-brief-before-handing-it-to-a-developer-or-agency.webp --- [Skip to content](https://weareaffective.com/learning-centre/how-to-audit-a-brief-before-handing-it-to-a-developer-or-agency#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # How to Audit a Brief Before Handing It to a Developer or Agency Table of Contents A brief arrives on a developer's desk and something quiet happens: every gap in it becomes a decision the developer makes alone. Not out of laziness or bad faith, but because work has to move forward, and silence gets filled. The assumption that wasn't written down becomes a feature that wasn't wanted. The scope that wasn't bounded becomes a project that never ends. The success condition that nobody named becomes a launch date that feels arbitrary and a product nobody can agree is finished. > A brief with unnamed assumptions hands every undecided question to someone whose job is to build, not to decide. We see this pattern often enough that we now treat the brief itself as a deliverable, not a preamble. Before any conversation about timelines or quotes, we read it the way a developer will read it: looking for what it does not say, what it assumes without evidence, and what it is quietly trying to smuggle in alongside the thing it is explicitly asking for. This article is a walkthrough of that audit. Each section covers a different kind of gap, why it matters, and what to do about it before you hand anything over. The cost of reading it carefully now is an hour. The cost of skipping it tends to land somewhere between a difficult conversation and a five-figure rewrite. ## What a Brief Is Actually Supposed to Do A brief is an alignment document. Its job is to put the person commissioning the work and the person doing it inside the same mental model of what is being built, for whom, and why. Not a wish list, not a mood board, not a product vision statement. A shared model. That distinction matters because developers and agencies quote against what they read, then build against what they understood. If those two things diverge, the gap shows up in the product, usually at a point where fixing it costs more than writing the brief properly would have. A brief that does its job answers four questions clearly. What is being built. Who it is for and what they need from it. What the boundaries of the work are. And what a finished, successful version looks like. If any of those four are vague, contested, or missing, the brief has not done its job, and no amount of good intention on either side will recover the lost ground once build begins. The brief is also a negotiation tool. When you hand it to a [developer or agency, they are using it](https://weareaffective.com/learning-centre/how-to-tell-whether-your-digital-problem-is-a-format-problem-or-a-brief-problem) to structure their quote. A well-written brief produces a quote that reflects the actual work. A vague one produces a quote with generous contingency built in, because the developer knows there are decisions to be made and is pricing for the time those decisions will take. ## Assumption Clarity: What Has Been Stated as Fact That Has Not Been Tested Most briefs contain several assumptions dressed as requirements. "Users want a single platform that handles everything." "The checkout flow should feel premium." "People in this market prefer simplicity over depth." These read like decisions. They are actually hypotheses, and an audit treats them as such. The practical test is to read each statement in the brief and ask: how do we know this? If the answer is "the founder said so" or "it seemed obvious" or "competitors do it this way", that is an assumption, not evidence. It may still be correct. But it should be named as something to validate, not built against as settled fact. We worked on a project aimed at expats living abroad, and the brief arrived with a clear picture of what the product should be. Discovery revealed that what the market actually needed was very far from what the client had assumed. Catching that before build began saved significant time and budget. The discovery phase cost a fraction of what the wrong build would have. On the audit, go through the brief line by line and flag every claim about user behaviour, user preference, or market need that is not backed by research. Not to challenge the thinking, but to decide: do we [validate this before we build](https://weareaffective.com/learning-centre/5-user-testing-methods-that-will-save-your-app-from-failure), or do we accept the risk that it might be wrong? ## Start your app project the *right* way We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Behavioural Intent: Who Is This For and What Are They Actually Trying to Do A brief that describes a user as "busy professionals aged 25 to 40 who value convenience" has not described a user. It has described a marketing segment. Those are not the same thing, and [building against a segment rather than a behaviour](https://weareaffective.com/learning-centre/how-to-write-a-behavioural-brief-that-protects-the-brand-through-the-build) produces a product that fits nobody precisely. The question a brief needs to answer is not who the user is demographically, but what they are trying to do, and what they are currently doing instead. That second part is the one that usually gets skipped. If a user is currently managing something manually and finds it adequate, there is no compelling case for a technical solution. The product only has a reason to exist where the current approach is genuinely failing the person using it. > A product only earns its place where the current approach is failing the person who needs to get something done. The brief should name the specific moment of friction: what the user is doing, where it breaks down, and how that failure feels. A skincare brand's replenishment tool solves a different problem than a wellness tracker's subscription reminder, even if both touch the same demographic. The emotional context of the friction matters as much as the functional gap. If the brief has a persona section, check whether it describes behaviour or biography. Age, income, and location are biography. "[She places an order on mobile while commuting](https://weareaffective.com/learning-centre/research-findings-from-our-own-work-where-lifestyle-brand-reorder-flows-break-do) but abandons at the payment step because her card details are stored on her home laptop" is behaviour. One of those gives a developer something to design against. The other gives them a stock photo. Ask the brief to describe the single most frustrating moment in the user's current process. If it can't, the user research is not done yet. ## Scope Boundaries: What Is Explicitly In and Explicitly Out Scope is the most abused section of any brief. The common failure is listing what is in without naming what is out. That absence is where project creep begins, because anything not explicitly excluded can reasonably be read as included, and developers build accordingly. A strong scope section uses two columns. What is being built in this phase. And what is intentionally deferred. Both lists need to exist, because "we'll add that later" only works if "later" is somewhere in the document and "that" is named. | In scope (this phase) | Out of scope (explicitly deferred) | | --- | --- | | User onboarding flow | Social login integration | | Product detail pages | User-generated reviews | | Checkout and payment | Saved payment methods | | Order confirmation email | Post-purchase loyalty programme | The second column is a commitment to building those features later, which protects the timeline, the budget, and the quality of what is actually in scope. A developer who knows the loyalty programme is out of scope will not architect the database to accommodate it. One who does not know will either build for it speculatively or ask mid-project, which costs time either way. If the out-of-scope list is empty, the brief is not ready. Go back and ask what would be cut first if the budget were halved. ## The Consolidation Trap: When One Brief Is Trying to Do Several Products' Jobs One of the most consistent problems we see in briefs from first-time product owners is the all-in-one premise. The product will do what app A does, plus what app B does, plus what app C does, but all in one place. The logic feels sound on paper. In practice, it almost always produces something that does each thing less well than the specialist alternatives, while costing more to build. We saw this directly on a [grassroots football app project](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-). The client compared individual features against best-in-class single-purpose competitors and kept asking for the booking process to be "more intuitive." We pushed back, but ultimately built the changes requested. They made little difference. The real problem was that the product was trying to do too many things at once. There was a reason those features existed across several separate apps. Despite genuine effort to create something cohesive and emotionally grounded, the result was overly complex, too verbose, and not right for the audience or its core purpose. A brief audit catches this by asking a simple question: could any section of this brief be extracted and made into its own standalone product? If yes, the brief is probably carrying more than one product's worth of ambition. That is not always fatal, but it needs to be a conscious decision rather than something discovered six months into build. The pre-launch founder in the football industry who came to us with a colour-coded spreadsheet mapping competitor products had the same instinct. Merge everything into one. The brief looked comprehensive. When we started asking why a user would choose the all-in-one over a specialised app, and whether consolidation would dumb down individual features, the premise began to unravel. Honest questions earlier save expensive rebuilds later. ## Success Definition: What Does Done Look Like and How Will You Know According to a self-reported survey by [Geneca](https://www.geneca.com/why-up-to-75-of-software-projects-will-fail/), up to 77% of software project respondents do not know how to tell when their project is done. That finding aligns exactly with what happens when a brief does not define success. Without a named condition for done, the project expands to fill the time available and the budget permits, or it ends arbitrarily at a launch date that felt far away when it was set. Success definition in a brief should operate at two levels. Functional completion and behavioural outcome. Functional completion is the easier one: which screens are built, which flows work end to end, which integrations are live. Behavioural outcome is harder and more useful: what does a user do in the first session, what does a retained user look like at week four, what number on what metric tells you the product is working? #### Functional completion List the specific flows that must work without error before the product is considered shippable. Not "the checkout works" but "[a new user can complete a purchase](https://weareaffective.com/learning-centre/why-product-owners-should-write-the-users-second-session-before-the-first-one) without a saved account, on mobile, in under three minutes." Specificity protects both sides. #### Behavioural outcome Name one or two user behaviours that indicate the product is doing what it was built to do. A fitness app might look for a second workout logged within seven days of the first. A hospitality booking tool might look for a completed reservation without a support contact. These are not guaranteed by launch but they define what you are aiming for. ## The Gaps Developers Will Quote Around but Not Fill Developers quote against what they can see in a brief. They do not typically flag what is missing, because identifying gaps is a strategic question, and most developers are quoting for a build, not a strategy engagement. The result is a quote that is accurate for the brief as written and silent on everything the brief did not address. The gaps that most consistently cause problems fall into a predictable set. Error states and edge cases are almost never in a brief, which means they are either not built or built inconsistently. Content is rarely scoped, so pages that need real words get placeholder text that never gets replaced. User flow for failed actions, like a declined payment or a product out of stock, tends to get designed only after someone reports it as a bug. - Error states for every primary user action - Empty states for lists or feeds before content exists - Content ownership: who writes it, by when, in what format - Failed flow recovery: what happens when something goes wrong - Device and browser coverage: what is explicitly supported - Accessibility requirements: what standard the product is being built to None of these are exotic. All of them get skipped regularly. An audit specifically looks for their absence, because a developer who does not see them in the brief will either omit them or price for them generously and not tell you which. ## What Happens When You Skip a Section and Build Anyway On a dating app project focused on verified profiles and preventing bots, the client chose to skip discovery for the messaging component and focus solely on onboarding. The result was a generic messaging feature that directly contradicted the product's core premise: it allowed automated and fake messages, which undid all the verification work done during onboarding. The mismatch meant the entire messaging section had to be rewritten. That cost approximately £15,000 in additional budget and two months of extra work. The failure was not technical. [The developers built what the brief described](https://weareaffective.com/app-development). The brief simply did not describe enough. The onboarding and the messaging were scoped separately, and nobody asked how they would need to talk to each other. That question belongs in the audit, before the quote is accepted. Skipping sections in a brief tends to produce one of three outcomes. The developer makes a reasonable assumption that turns out to be wrong. The developer builds something technically correct that is behaviourally incoherent with the rest of the product. Or the gap surfaces mid-project as a change request, which is the most expensive way to answer a question that could have been asked on day one. Before accepting any quote, read the brief again and mark every section that was written quickly. Those sections carry the highest risk of producing something that does not fit. ## How to Walk Through the Brief Before You Accept a Quote The brief audit is most useful when it is done as a structured walkthrough rather than a read-through. A read-through produces the impression of a document. A walkthrough produces a list of questions, and questions are what protect you before build begins. Run the walkthrough in this order. 1. Read the brief once without annotating anything. Get the overall shape of it. 2. Go back through and flag every assumption: a [claim about users, the market, or behaviour](https://weareaffective.com/learning-centre/is-dirty-data-ruining-your-mobile-apps-purpose-what-app-developers-need-to-know) that is not backed by named research. 3. Find the scope section and check for an explicit out-of-scope list. If it does not exist, write one before continuing. 4. Look for success definitions. If the brief describes what to build but not what success looks like after launch, add that section. 5. Check for the gaps listed in the previous chapter: error states, empty states, content ownership, failed flows, device coverage. 6. Ask whether the brief is trying to do one product's job or several. If several, decide whether that is intentional and scoped for it. Once the walkthrough is complete, take the list of questions to whoever wrote the brief before the quote is accepted. Not after. The developer will have the same questions, but they will answer them quietly in their own head, and the answers will show up in the product six months later. According to research summarised by [arXiv, 2020](https://arxiv.org/abs/2007.01761), 78% of requirements-related rework traced back to avoidable gaps in shared understanding between those commissioning work and those building it. The walkthrough is how you close those gaps before they become rework. ## Conclusion A brief that has not been audited is a risk document pretending to be a plan. Every vague section is a decision deferred to someone who was not in the room when the product was conceived and has no way to know which choice the team would have made. That is a structural problem with how briefs get written and handed over. The audit we have described here does not require a specialist. It requires someone willing to read the brief slowly, ask "how do we know this" at every claim, and name what is missing before the work begins. An hour of that kind of reading consistently surfaces the questions that would otherwise surface as change requests, budget overruns, or a product that launches and quietly does not work for the people it was built for. The grassroots football app, the dating app's messaging section, the expat product: in each case, the gap that caused the problem was visible in the brief before build started. The question that would have caught it simply did not get asked in time. Ask it now, before the quote is accepted and the work begins. If you would like a second pair of eyes on a brief before it goes out, [let's talk about your project](https://weareaffective.com/get-started). ## Frequently Asked Questions What is the purpose of auditing a brief before sending it to a developer or agency? Auditing a brief ensures that any gaps, vague assumptions, or missing information are identified and resolved before build work begins. Without this step, developers are left to fill in the blanks themselves, which can result in unwanted features, endless scope creep, and costly rewrites. What are the four questions a well-written brief should clearly answer? A good brief should clearly explain what is being built, who it is for and what they need from it, what the boundaries of the work are, and what a finished and successful version looks like. If any of these four areas are vague or missing, the brief has not done its job. How does a vague brief affect the quotes you receive from developers or agencies? When a brief is vague, developers and agencies build generous contingency into their quotes because they know undecided questions will take time to resolve during the project. A well-written brief produces a quote that more accurately reflects the actual work involved, which is better for everyone. What is the difference between an assumption and a requirement in a brief? A requirement is a decision backed by evidence or testing, whereas an assumption is a hypothesis presented as settled fact. Statements like 'users prefer simplicity over depth' may sound like decisions, but without evidence to support them they should be treated as things to validate, not things to build against. How can I tell whether a statement in my brief is an assumption rather than a fact? Apply a simple test to each statement by asking how you know it to be true. If the honest answer is 'the founder said so', 'it seemed obvious', or 'competitors do it this way', then it is an assumption and should be labelled as something to validate before build begins. Why should a brief be treated as a deliverable rather than just a starting point? Treating a brief as a deliverable means it receives the same scrutiny and care as any other piece of work produced during a project. This approach surfaces problems early, when fixing them costs relatively little, rather than allowing them to emerge during build when the consequences are far more expensive. What can happen if assumptions in a brief are never tested before development starts? If untested assumptions are built against as though they were facts, the resulting product may not match what the market actually needs. The article gives the example of a project aimed at expats where discovery revealed the market needed something very different from what the client had assumed, with catching this early saving significant time and budget. How much time should I expect to spend auditing a brief properly? The article suggests that reading and auditing a brief carefully takes roughly an hour. That investment is modest compared to the alternative, which the article describes as landing somewhere between a difficult conversation and a five-figure rewrite. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.