--- title: How do I brief an app development agency? description: Learn how to write an effective app development brief, covering problem definition, user needs, budget and scope to get the best from an agency. image: https://weareaffective.com/hubfs/learning-centre-images/how-do-i-brief-an-app-development-agency.webp --- [Skip to content](https://weareaffective.com/learning-centre/how-do-i-brief-an-app-development-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 do I brief an app development agency? Table of Contents A brief is not a wish list. It is not a list of features you would like to see, or a rough description of an app you saw on your phone last week that you want something similar to. A brief is a document that tells an agency what problem exists, who has it, and why solving it matters. Without that foundation, the development process that follows is essentially guesswork dressed up as delivery. > A brief built on enthusiasm alone gives an agency nowhere to go except where you point them. We see this regularly. A founder or product owner arrives with enormous enthusiasm, a name for the app, a colour palette they like, and a rough sense of what it should do. What they have not done is sit with the harder questions: [what specifically fails for users right now](https://weareaffective.com/learning-centre/what-behavioural-research-looks-like-when-its-done-to-inform-not-to-justify), what would genuinely change if the app existed, and how they would know whether it had worked. Those questions feel slower and less exciting than picking a tech stack, but they are what separate a product that reaches users from one that absorbs a budget and disappears. This article walks through how to write a brief that actually works, what to include, what to leave open, and how to approach the relationship with an agency so that both sides end up building the right thing. Briefing well is the first piece of real product thinking you will do, and everything that follows depends on getting it right. ## What a brief actually is (and what it is not) A brief is a problem statement, not a specification. A specification tells a development team what to build. A brief tells them what you are trying to achieve and why, so they can work with you to figure out what to build. That distinction matters enormously, because most agencies worth working with will push back on the how and ask harder questions about the why. If your brief reads like a feature list, you have skipped the part that makes everything else coherent. A good brief answers a small number of questions with genuine clarity. Who is this for? What do those people currently do instead? What is failing about that? What would success look like from their point of view, and from yours commercially? Those answers do not need to be long. They need to be honest and specific. #### What a brief is not A brief is not a pitch deck recycled. Pitch decks are written to persuade investors, so they emphasise opportunity and downplay risk. A development brief needs to go the other way, surfacing constraints, uncertainties, and known unknowns so the agency can plan around them. If your brief reads like everything is figured out, a good agency will know that something has been smoothed over. A brief is also not a contract. It is a starting point for a conversation, and a good agency will treat it as one. The strongest briefs we receive are written by people who know what they do not yet know, and who frame that openly. That kind of honesty gives us room to help. ## The problem definition: what are you really trying to solve? The most common weakness in a brief is a problem definition that describes a solution rather than the problem itself. "We need an app that lets users track their workouts and share them with friends" is a solution. The problem underneath it might be that [people who exercise alone lose motivation](https://weareaffective.com/learning-centre/fitness-app-trends-2026-what-users-really-want-from-their-workout-apps) within six weeks, or that fitness communities exist on platforms not built for accountability. Those are two different problems, and they lead to two very different products. Getting to the real problem takes effort. It often means questioning your own assumptions about what users need, and sitting with some uncertainty before reaching for an answer. We ask clients to tell us what people do today without their product, and how they feel about that. If the honest answer is "they manage fine", that is useful information. It means the product needs to offer something meaningfully better, and the brief should say what that is. A pre-launch founder in the football industry came to us with a colour-coded spreadsheet mapping out competitor products, with the aim of merging several existing apps into one. When we began asking questions about prospective users, such as why someone would choose an all-in-one product over specialised tools and whether consolidation risked dulling the features people actually used, the founder became deflated. Our job is to be honest about what will make a product succeed. Building on surface confidence alone serves no one. ## 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 ## What you need to know about your users before you brief anyone You do not need a full research programme before you brief an agency. But you do need more than a demographic sketch. Knowing your target user is "women aged 25 to 40 interested in wellness" tells an agency almost nothing about how to design for them. What matters is behaviour: what those people do right now, where the friction sits, and what would have to be true for them to change. At the very minimum, your brief should include some direct knowledge of the people you are building for. That means speaking to them, not just thinking about them. What do they currently use? What frustrates them about it? What would make them switch? If you have not spoken to at least a handful of prospective users before briefing an agency, you are building on assumption, and that carries real risk. > Speaking to five real users before briefing is worth more than a hundred assumptions about who they are. We ran focus groups with social housing tenants on a concierge app project for a property developer, to understand what actually builds community in a shared building. The insight was specific: community grows from familiarity, from knowing names, families, and pets. That changed the entire product direction. The app took on mundane building management tasks, while the design actively encouraged face-to-face contact rather than replacing it. That pivot came from real user knowledge, not from the client's initial instinct about what residents would want. Write down three things you believe to be true about your users, then ask yourself what evidence you have for each one. If the honest answer is "it seems obvious" or "I would feel that way", those are assumptions, and your brief should name them as such. ## Your commercial context, constraints, and success criteria An agency cannot help you build a viable product if they do not understand the commercial picture around it. That means sharing more than you might instinctively feel comfortable sharing. Your revenue model, your launch timeline, your investor expectations, your runway, and what happens if the product does not gain traction inside twelve months: all of these shape what the right product looks like and how it should be phased. Success criteria are where briefs most commonly go vague. "A successful product" is not a success criterion. A specific number of downloads is not one either, if it has no connection to retention or revenue. The most useful success criteria are behavioural: what will users do differently, and how often, if the product is working? What does your business need to see from the product in year one to justify continued investment? #### Measuring what matters Think about what you can actually measure, and when. An app that aims to build a habit in users needs a different success measure from one that aims to reduce a specific support cost. Getting clear on this before briefing means the agency can design for your actual goal rather than a proxy of it. According to [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 is a remarkable number, and it points to exactly this gap. If you cannot describe what done looks like at the outset, scope will drift and the project will cost more and deliver less than it should. ## Scope, budget, and timeline: being honest before work begins Scope, budget, and timeline are the three things clients most often misrepresent in a brief, usually because they fear that honesty will limit what they get back. The opposite is true. An agency that knows your real budget can design a process that fits it. An agency working to a number you invented to protect your negotiating position will either overpromise or build something that needs reworking. A property developer came to us with a suggested budget already formed and a pre-built idea of what they wanted, looking for validation rather than a proper scoping process. We convinced them to run a full discovery phase including focus groups and user workshops. What emerged was that the product was going to be far simpler than they had imagined. Many of the planned features were dropped, and the focus shifted to creating a genuine human connection with the product rather than replacing building systems that already worked. The result was a better product at a lower cost than the original brief would have produced. Share your real budget, even if it feels uncomfortable. Frame it as a constraint to design around, not a ceiling you are defending. Agencies who respond to honesty with creativity are the ones worth working with. #### Scope as a starting point Scope in a brief should describe what the first version of the product needs to do, not the full roadmap of everything it might eventually do. A brief that lists every possible feature signals that no prioritisation has happened yet, and prioritisation is some of the most valuable thinking you can do before engaging anyone. The brief should reflect that thinking, not defer it. ## What happens when the brief is built on assumptions instead of evidence Briefs built on untested assumptions tend to produce products with a specific failure pattern. The product is built as specified, users do not behave as expected, and the retrospective explanation is almost always the same: the problem was defined from the inside, without enough contact with the people who had it. We worked on a grassroots football club app where the client's brief was built around a vision of combining several different apps into one product. We advised starting with a limited feature set, releasing it, testing it with real users, and growing from there. The client insisted on building everything at once. The scope kept expanding. The budget kept rising. The product never reached market because it became unnecessarily complex. The warning signs were visible early, and so was the advice, but the brief had already committed the client to a scale of ambition that had no foundation in [what users actually needed](https://weareaffective.com/learning-centre/the-hidden-complexity-of-delivery-apps-what-every-business-owner-should-know). According to [The Standish Group's CHAOS Report 2015](https://www.studocu.com/da/document/erhvervsakademi-aarhus/systemudvikling/chaos-report-2015-the-standish-group/19026719), 70% of app projects fail due to misaligned expectations and market misunderstanding. A brief that papers over uncertainty rather than naming it is the starting point for that misalignment. Before finalising your brief, list every assumption it rests on. Then mark each one as tested or untested. If more than half are untested, the brief is not ready to send. ## How a good agency will challenge and pressure-test your brief A good agency will not simply receive your brief and start designing. They will ask questions that feel uncomfortable, and those questions are exactly what you are paying for. If an agency takes your brief at face value and returns a proposal within 48 hours, treat that as a signal worth paying attention to. The brief you wrote in a few days cannot contain all the complexity of the product you are trying to build. Our approach when a client arrives with what seems like a fully formed brief is to ask the questions that surface what is underneath it. We look at what problem the product is solving and how users are currently managing without it. We ask what would have to change in user behaviour for the product to work, and whether there is evidence that change is realistic. Sometimes those questions confirm that the brief is solid. Often they reveal that one or two core assumptions need testing before any design work begins. #### Constructive challenge is not obstruction When we need to help a client pivot, rethink, or in some cases not proceed with a product at all, that is done with a shared goal. We are on the same side. The purpose of challenge is not to slow things down but to make sure what gets built is worth building. An agency that tells you everything looks great when the brief has real gaps is being comfortable, and that costs you money later. ## What to expect from a proper discovery phase Discovery is where the real understanding of the product gets built, and it looks different from what many clients expect. A discovery phase that consists of a single meeting and a mood board is not discovery. A proper discovery process goes deeper into the psychology of the product and the people it is for. Our discovery sessions with clients involve structured exercises that are sometimes a little unexpected. Simon and Josh, our UX designer and strategy lead, run sessions with clients using games designed to surface unfiltered thinking, including answers the client did not know they had. We ask clients to come to these sessions relatively fresh, without over-preparing, because the most useful responses tend to come before the official version has been rehearsed. 1. Define who the brand and product are as if they were people, with a specific character and voice. 2. Map the [emotional journey a user takes from discovering](https://weareaffective.com/learning-centre/what-curiosity-looks-like-in-a-first-session-and-why-most-products-design-past-i) the product to depending on it. 3. Identify the moments where the current approach fails users functionally and emotionally. 4. Pressure-test the proposed solution against real user behaviour and competing alternatives. 5. Agree on the minimum version of the product that could be tested with real users. According to [Nielsen Norman Group](https://www.nngroup.com/articles/discoveries-in-industry-revealed/), investing properly in discovery reduces the risk of project failure by 75%. That is a large return on what is usually a modest investment in time and budget. ## The brief as a living document: keeping it useful throughout the project A brief written before discovery begins will not be exactly right by the time discovery ends. That is the process working correctly. The mistake is treating the original document as fixed, refusing to update it when new information emerges, and measuring the project against decisions made before anyone had spoken to a single user. The brief should be updated at the end of discovery to reflect what has been learned. It should be revisited when scope decisions are made, when priorities shift, and when the [product meets real users for the first time](https://weareaffective.com/learning-centre/what-a-behavioural-retrospective-looks-like-three-months-after-launch) and their behaviour reveals something unexpected. A brief that cannot be revised is a document protecting past decisions rather than guiding current ones. #### Who owns the brief Ownership of the brief matters more than people expect. On the grassroots football app project, two co-founders with very strong opinions were both deeply embedded in the world the app was designed for, both convinced that more features were obvious and already implied, and the combination made it impossible to hold scope. A brief needs one person on the client side with the authority to make decisions about it, and that person needs to be willing to say no to additions that are not in the document. | Brief version | When to update | Who reviews it | | --- | --- | --- | | Initial brief | Before first agency conversation | Client decision-maker | | Post-discovery brief | After discovery phase concludes | Client and agency together | | Revised brief | After first user testing round | Client decision-maker with agency input | | Phase 2 brief | Before building beyond MVP | Full team review | ## Conclusion Briefing an [app development agency well](https://weareaffective.com/app-design-agency) is a discipline, and most of it happens before you open a document. It is the thinking you do about the real problem, the honest conversations about what you know versus what you are assuming, and the willingness to hold the process open long enough to let discovery do its job. The brief that emerges from that thinking is a better product. The projects that struggle most are rarely the ones with the smallest budgets or the most complex ideas. They are the ones where the brief protected a vision instead of testing it, and where the development process followed instructions that should have been questioned. The grassroots football app that never launched was not a failure of execution. It was a failure of the brief that preceded it, and of the unwillingness to revise that brief when the evidence pointed somewhere different. A brief that names what you know, what you are assuming, and what you need to find out gives an agency the foundation to do genuinely useful work. It also signals that you are the kind of client who will make that work go well. That matters more than most people realise when choosing who to build with. If you are working through what your brief should say, or you are not yet sure whether you are ready to brief anyone, [let's talk about your product](https://weareaffective.com/get-started). ## Frequently Asked Questions What is the purpose of an app development brief? A brief is a document that defines the problem you are trying to solve, who experiences it, and why solving it matters. It is not a feature list or a wish list. It gives an agency the foundation they need to help you build the right product, rather than simply building what you point them towards. How is a brief different from a specification? A specification tells a development team exactly what to build, whereas a brief explains what you are trying to achieve and why. The distinction matters because a good agency will use a brief to ask harder questions and work with you to determine what should actually be built, rather than just executing a list of instructions. Can I use my pitch deck as the basis for my brief? No, a pitch deck is written to persuade investors, so it tends to emphasise opportunity and downplay risk. A development brief needs to surface constraints, uncertainties, and known unknowns so the agency can plan around them. If your brief reads as though everything is already figured out, a good agency will suspect something has been smoothed over. What should the problem definition in my brief actually include? It should describe the underlying problem your users face, not a solution you have already settled on. For example, saying you need an app that tracks workouts describes a solution, whereas explaining that people exercising alone tend to lose motivation within six weeks describes the actual problem. That distinction leads to very different products, so being precise here is critical. What questions should a good brief answer? A brief should clearly answer who the product is for, what those people currently do instead, and what is failing about that. It should also explain what success would look like from the user's perspective and from a commercial one. These answers do not need to be lengthy, but they do need to be honest and specific. Is it a problem if I do not have all the answers when writing my brief? Not at all. The strongest briefs are often written by people who openly acknowledge what they do not yet know. Framing your uncertainties honestly gives an agency room to help you work through them. A brief is a starting point for a conversation, not a finalised plan. Why does briefing well matter so much at this early stage? Briefing well is the first real act of product thinking you will undertake, and everything that follows depends on it. Without a clear problem definition and honest context, the development process becomes guesswork. Products built on enthusiasm alone rather than genuine insight tend to absorb budget without ever reaching the users they were meant to serve. Should I include my design preferences, such as colours or similar apps I like, in the brief? These can be useful as reference points, but they should not form the core of your brief. Arriving with a colour palette and a name without having addressed the harder questions about user need and measurable success means the agency has very little of substance to work with. Design direction is most useful once the problem and the people it affects are clearly defined. ## 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.