--- title: How to Scope a Pre-Build Research Phase When the Budget Is Already Signed off for the Build description: How to scope a short research phase before build begins, what it covers, and how to frame it to your agency without derailing the project. image: https://weareaffective.com/hubfs/learning-centre-images/how-to-scope-a-pre-build-research-phase-when-the-budget-is-already-signed-off-for-the-build.webp --- [Skip to content](https://weareaffective.com/learning-centre/how-to-scope-a-pre-build-research-phase-when-the-budget-is-already-signed-off-fo#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 Scope a Pre-Build Research Phase When the Budget Is Already Signed off for the Build Table of Contents The budget is signed. The contract is agreed. The agency is ready to open their design tools and start building. And you are sitting with a quiet, uncomfortable feeling that something important has not been answered yet. You are not sure exactly what, but you know that jumping straight into build without understanding your users properly feels like a risk nobody has formally acknowledged. > Skipping pre-build research does not save time. It moves the cost later, where it is far harder to absorb. That feeling is worth listening to. A pre-build research phase is the structured way to answer the questions that, if left open, will cost you far more than the research itself. The challenge is that nobody budgeted for it separately. The money is already allocated. The timeline is already set. And asking for more time before the work has technically begun can feel like you are creating a problem rather than solving one. This article is about how to scope that phase anyway, within a signed contract, without derailing the project or renegotiating from scratch. We will cover what the phase actually contains, how to frame it to your agency, what artefacts to insist on, and what it costs when you skip it entirely. We have seen this play out on enough projects to know the pattern. The question is how to create the space for the research when the paperwork says you should already be building. ## Why You're Right to Pause Before Build Begins Build phases move fast, and once they start they are expensive to redirect. Developers working at pace on a defined specification are not positioned to absorb a fundamental change in direction mid-sprint. If it turns out, three weeks into build, that the onboarding flow was solving the wrong problem, the cost of unwinding that work is real, measurable, and avoidable. According to [McKinsey and the University of Oxford](https://www.mckinsey.com/~/media/McKinsey/dotcom/client_service/BTO/PDF/MOBT_27_Delivering_large-scale_IT_projects_on_time_budget_and_value.ashx), IT projects without MVPs run an average of 45% over budget and deliver 56% less value than expected. The research phase is the thing that ensures you are building the right minimum viable product in the first place, not just a stripped-back version of the wrong one. The instinct to pause is also evidence that you understand something about your users that the brief may not yet capture. Most project briefs are written from the inside out: here is what we want to build, here is what we think users need. A research phase turns that around and asks [what users actually do, what they expect](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one), and where the product as currently conceived would let them down. Pausing is the decision to spend a short period of structured inquiry so that the build itself is faster, cleaner, and less likely to require expensive rework on the other side. ## What a Pre-Build Research Phase Actually Is (and Isn't) A pre-build research phase is a defined period, usually one to three weeks, in which the team answers specific questions about users, behaviour, and product-market fit before any design or development work locks in. It produces decisions, not just observations. At the end of it, the team knows things they did not know before, and those things change what gets built. It is not a delay dressed up in process language. It is not a series of internal workshops where the team debates its own assumptions. And it is not a competitor analysis that tells you what features other products have, which is a common substitute that provides exactly zero insight into whether your users want those features too. #### What it contains The phase typically includes [user interviews, behavioural mapping, and emotional response testing](https://weareaffective.com/app-user-research) against early concepts or prototypes. The questions we focus on are psychological as much as functional: what does the user feel at each stage, what creates anxiety, what builds trust, and where does the product need to work harder to earn attention? This goes well beyond a standard discovery checklist and into understanding the brand and product as a person interacting with other people. #### What it replaces It replaces assumption. The signed brief contains assumptions about who the user is and what they need. Some of those assumptions will be right. Some will not. The research phase finds out which is which before the budget is spent acting on them. ## Design that understands *your* users We build app experiences around real user behaviour, not assumptions. Research, psychology-driven design and technical specs that turn users into loyal advocates. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## How to Scope One to Three Weeks Without Unravelling the Contract The practical challenge is real. The contract describes a build, not a research phase. The timeline was agreed on the assumption that work would begin immediately. Asking for additional time and budget before a single screen has been designed can feel like you are changing the deal. The way through is to position the research phase as a pre-condition of the build, not an addition to it. The build is still happening. The contract is still valid. What you are asking for is a short period at the front of the project in which the inputs to the build are confirmed, rather than assumed. That is a different conversation from "we need more money." We work with clients who come in with a suggested budget and a pre-formed idea of what they want to build, looking for validation rather than genuine discovery. When we convince them to run the research phase first, what consistently happens is that the product changes, and the product becomes better. On a concierge app project for a property developer, we ran focus groups and user workshops before a single line of development began. The research revealed the product needed to be far simpler than originally envisaged. Features were dropped. The focus shifted entirely. The result was a better product at a lower cost than the original specification would have produced. A research phase does not add cost to a well-scoped project. It tends to reduce it, because it removes the work that would otherwise have been built and then removed. Frame the research phase to your agency as a short period for confirming build inputs, not as a request for additional scope. The distinction matters for how it lands internally and commercially. > A research phase that changes the product has done exactly what it was supposed to do. That is not a failure of planning. In terms of structure, one week is enough to run user interviews and map findings. Two weeks allows for a second round of validation. Three weeks creates space for [concept testing and iteration before the brief](https://weareaffective.com/learning-centre/what-a-behavioural-concept-test-reveals-that-a-prototype-test-cannot) is finalised. Which of those you need depends on how much uncertainty is baked into the current specification. ## How to Frame It to Your Agency Most agencies will welcome a properly scoped research phase, because building on confirmed assumptions is faster and cheaper for them too. What agencies resist is scope creep dressed as research, which means vague objectives, moving deliverables, and an open-ended timeline. Be specific about what the phase needs to produce and when it will end. Come to the conversation with three things: a defined set of questions the research needs to answer, a proposed timeline with a clear end date, and a description of the decisions those answers will inform. That is a research brief, and an agency can work with it. "We need to do some research before we start" is not a brief, and it will be met with commercial caution. #### Who needs to be in the room The debrief at the end of the research phase is where the decisions get made, and who attends it matters considerably. The risk is about mindset and number. Too many people brings too many competing positions, and anyone who has already decided what the product should look like will actively resist findings that contradict their view. The people you want in the room are those who are open to what the research actually shows, who value user insight, and who have the authority to act on it. #### What the agency needs from you The agency needs your access to users, your honesty about what the current brief does and does not know, and your willingness to act on findings rather than treat them as a formality. Research that feeds directly into the build is worth running. Research that produces a report nobody acts on is not. ## What to Protect in Scope: The Four Questions That Must Be Answered Not every question is worth a research phase. The ones that are worth it are the ones where getting the answer wrong will require significant rework during build, or where the current answer is an assumption rather than a confirmed fact. Four questions consistently prove their value. 1. [Who is the actual user, and what is their emotional state](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you) when they reach this product? Not the demographic profile, but the specific context of use and the feeling they arrive with. 2. Where does the product as currently specified create friction, confusion, or distrust? This cannot be answered by the team who designed the specification, it requires someone who has never seen it before. 3. [Which features are genuinely needed at launch](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-), and which are assumptions about what users want? A pre-build research phase is the only reliable way to separate these two categories. 4. Does the product's tone, language, and visual direction match the emotional expectations of the people it is aimed at? These four questions do not require months of research to answer. They require [direct contact with real users, structured observation](https://weareaffective.com/learning-centre/5-user-testing-methods-that-will-save-your-app-from-failure), and honest reporting. A focused two-week phase can answer all four well enough to confirm the build direction or change it before it is too late to change affordably. Write the four questions down before the research begins and share them with the research team. The phase is only useful if it produces answers, not a general sense of user sentiment. ## The Artefacts You Should Insist On Before Build Starts A research phase that ends with a conversation rather than a documented output has not produced anything the build team can work from. Insist on written artefacts. They are the transfer mechanism between research and build, and without them the findings live only in the heads of whoever was in the debrief. The artefacts that matter most are the ones that describe user behaviour and decision-making in enough detail that a developer or designer who was not present in the research sessions can build to them. A general summary is not enough. #### What to ask for - A user behaviour map showing the emotional journey through the product's key flows - [A prioritised list of friction points](https://weareaffective.com/learning-centre/how-to-structure-a-behavioural-risk-register-before-you-write-a-single-user-stor), with notes on which are structural and which are surface-level - A revised feature set with clear notes on what was dropped and why - A tone and language guide that reflects what users actually responded to, rather than what the brand team assumed #### What these replace in the build brief These artefacts replace the assumption-based sections of the original brief. They do not add to the brief, they update it. A build team working from a brief confirmed by real user research moves faster and produces fewer rounds of revision than one working from internal opinion alone. The artefacts are the point of doing the research at all. ## What Happens When You Skip It: The Real Cost of Proceeding Blind The cost of skipping pre-build research is not always visible at the start. It tends to appear several weeks into build, when something that seemed straightforward turns out to contradict the product's core premise, and the team has to stop and work out what to do. We worked on a dating app focused on verified profiles and preventing bots. The client chose to skip discovery for the messaging component of the product, wanting to focus the research budget solely on the onboarding process. The reasoning was understandable: onboarding felt like the harder problem. What happened next was not. The messaging feature was built as a generic system, and that generic system allowed automated and fake messages, which directly undermined the verification work done throughout onboarding. The mismatch between the two halves of the product was fundamental, and the only fix was a complete rewrite of the messaging section. That rewrite cost approximately £15,000 in additional budget and added two months to the project timeline. The discovery that would have prevented this was not complicated. A single session exploring how users expected the messaging system to work, given what they had just experienced during onboarding, would have surfaced the contradiction before any code was written. If budget pressure means the research phase must be reduced, protect the questions about the product's core user flows first. Surface-level decisions can be iterated after launch. Structural ones cannot. According to [Business of Apps](https://www.businessofapps.com/insights/top-reasons-why-mobile-apps-fail-to-make-a-mark-in-the-market/), 42% of apps fail because they were launched without prior market research. The statistic is a number, but the dating app story is what the number actually means in practice. ## When the Research Changes What You're Building This is the outcome that clients sometimes treat as a failure of planning and should instead treat as the [research working correctly](https://weareaffective.com/learning-centre/how-to-test-a-product-concept-with-behavioural-realism-rather-than-interview-ent). If the pre-build phase reveals that the product as currently specified will not serve its users well, that is the most valuable finding the research could produce, and it is infinitely cheaper to act on before build begins than after. We ran focus groups with social housing tenants on a concierge app project for a property developer. The client wanted the product to function as both a full-service building management utility and a community-building social tool. Running those two goals in parallel sounded reasonable internally. The research showed they were at odds with each other. What the tenants told us was that community comes from familiarity, from knowing your neighbours' names, their families, their pets, the kind of knowledge that comes from face-to-face contact. The app could not manufacture that. What it could do was handle the mundane building management tasks that currently got in the way of those conversations. So that is what it did. The product was redesigned to take friction out of the background and put human interaction at the front. That pivot was not a failure of the original brief. It was what a research phase is supposed to produce. A brief written from the inside cannot know what users already know about how community actually works. Only the users can tell you that, and only if you ask them before the product is built to the wrong specification. ## Red Flags That the Phase Isn't Being Done Properly A research phase that looks like research but does not function as research is worse than no research, because it creates false confidence. There are clear signs that the phase is not doing what it needs to do. #### Signs in the process - The research sessions only include internal stakeholders, not actual users or potential users - The brief for the research phase has not changed from the build brief it was meant to interrogate - The [findings are presented as confirmation of what was already planned](https://weareaffective.com/learning-centre/how-to-run-a-concept-test-that-doesnt-just-confirm-what-the-team-already-believe), with no friction points surfaced - The debrief is attended by people who made the decisions the research was meant to test, and those people are visibly not open to being wrong #### Signs in the output If the research phase produces no changes to the feature set, no additions to the tone guidance, and no friction points the team had not already identified, one of two things is true: either the original brief was remarkably accurate, or the research did not dig deep enough. The first is possible. The second is more common. We walked away from a project involving a fairly standard social product because the client wanted to go straight into redesigns without any discovery work at all. The emotionally led, user-centred phase we consider non-negotiable was not something they were willing to engage with. Rather than run a phase the client would not act on, we declined the project entirely. A research phase that exists to satisfy a process without influencing decisions is a cost with no return. ## Conclusion A signed build budget does not mean the questions are answered. It means the questions are about to become expensive if they remain open. A pre-build research phase is how you close those questions in a structured, time-limited way that protects the build rather than delaying it. Scope it as one to three weeks depending on how much uncertainty sits in the current brief. Frame it to your agency as a confirmation of build inputs rather than a renegotiation of scope. Insist on written artefacts that the build team can work from directly. And protect the research questions that relate to the product's core flows above everything else, because those are the ones that, if answered wrongly, produce the kind of rework that costs £15,000 and two months and lands in a post-mortem that nobody wanted to write. The fitness and wellness product we worked with, two co-founders new to app development, is the other side of this. Without a clear research phase anchoring decisions, that project cycled through approval and reversal until the budget was gone, never progressing beyond design. The research phase is the structure that prevents a project from becoming a conversation that never ends. If you are about to start a build and that quiet feeling has not gone away, it probably should not. [Let's talk about your pre-build research phase](https://weareaffective.com/get-started) and work out what it needs to answer before the first sprint begins. ## Frequently Asked Questions Why should I push for a research phase when the budget is already signed off? Skipping pre-build research does not eliminate cost, it simply moves it to a later stage where it is far harder to absorb. If a fundamental problem with the product is discovered mid-build, unwinding that work is measurable and expensive, whereas a short research phase at the start is comparatively cheap. How long does a pre-build research phase typically take? A pre-build research phase usually lasts between one and three weeks. This is a short, defined period focused on answering specific questions about users and behaviour before any design or development work becomes locked in. Will asking for a research phase mean renegotiating the entire contract? Not necessarily. The goal is to create space for the research within the existing agreement rather than starting from scratch. It is about framing the phase as a way to protect the investment already committed to, not as a request for additional budget. What is the difference between a research phase and simply running internal workshops? A research phase involves structured inquiry into what real users actually do and expect, rather than debating internal assumptions. Internal workshops rarely surface the kind of insight that changes what gets built, whereas proper user research does. Is a competitor analysis a suitable substitute for user research? No. A competitor analysis tells you what features other products have, but provides no insight into whether your users actually want or need those features. User research focuses on behaviour and expectations specific to your audience. What are the risks of skipping pre-build research entirely? Research from McKinsey and the University of Oxford found that IT projects without MVPs run an average of 45% over budget and deliver 56% less value than expected. Without research, there is a real risk of building a stripped-back version of the wrong product altogether. How should I frame the research phase to my agency? Position it as a way to make the build faster, cleaner, and less likely to require expensive rework after launch. Agencies benefit from clearer direction, so framing the research as something that protects their work as much as yours is likely to land well. What should a pre-build research phase actually produce? It should produce decisions, not just observations. By the end of the phase, the team should know specific things about users and behaviour that they did not know before, and those findings should directly influence what gets built. ## 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.