--- title: App Idea Validation the Lean Process for Testing Market Demand description: Learn how lean app validation helps you test real market demand before you build, avoid costly missteps and scope a product users actually want. image: https://weareaffective.com/hubfs/learning-centre-images/app-idea-validation-the-lean-process-for-testing-market-demand.webp --- [Skip to content](https://weareaffective.com/learning-centre/app-idea-validation-the-lean-process-for-testing-market-demand#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 # App Idea Validation the Lean Process for Testing Market Demand Table of Contents Most founders who come to us have already spent weeks, sometimes months, working on their idea before anyone has asked a single question of a real user. They have named the app, sketched the interface, mapped out the features, and built a clear picture in their head of how it will work. What they have not done is check whether anyone outside that picture actually needs it. > The question is whether you are solving a real problem people will pay for, or whether you are in love with the solution. Validation gets described as a phase of the process, something that happens before the build. In practice, it is more of a decision point. A founder either commits to testing their assumptions with real people before spending serious money, or they treat their own conviction as sufficient proof and move straight to development. The first route is slower at the start. The second route is almost always slower overall, and considerably more expensive. Lean validation exists to answer that question cheaply and quickly, [before a development contract is signed](https://weareaffective.com/app-planning-strategy). It is the mechanism by which a founder finds out whether they have a business or a personal project. The two can look identical from the inside, and very different from the outside, which is exactly why the outside view matters. ## Why Validation Fails Before It Starts The most common reason validation fails is that founders approach it having already decided the answer. They want confirmation, not information. So they look for evidence that supports what they already believe, and they structure their research, consciously or not, to find it. We see the earliest version of this when a founder arrives with a colour-coded spreadsheet. A pre-launch founder in the football industry came to us with exactly that, a detailed competitive map showing how several existing products could be merged into one. He was visibly pleased with what he had built. When we started asking questions about prospective users, specifically why someone would choose an all-in-one product over the specialised tools they already used, and whether consolidating features would inevitably dilute each of them, the energy shifted. He became deflated. The spreadsheet had felt like progress. The questions revealed it was actually a way of avoiding a harder conversation about whether the product was needed at all. That is where many founders are before validation even begins. A competitive mapping exercise gives you something to show, something to point to. It costs nothing emotionally because nobody can push back against a spreadsheet. Speaking to prospective users is different. A user can say they would not use it. A user can prefer a competitor. A user can reveal that the problem you are solving is not really a problem for them. The spreadsheet cannot do any of that, which is precisely why it feels safer. ## The 42 Per Cent Problem: What Skipping Validation Actually Costs According to [Business of Apps](https://www.businessofapps.com/insights/top-reasons-why-mobile-apps-fail-to-make-a-mark-in-the-market/), 42 per cent of apps fail because they were launched without prior market research. Simon uses this figure as a starting point rather than a headline, because the real story is not the number itself but what it tells you about where in the process things go wrong. The 42 per cent are not failed products that ran out of money mid-build, or products that were technically flawed, or products that were poorly marketed. They are products that nobody wanted. The problem was never the execution. It was the premise. And the premise could have been tested relatively cheaply before a single line of code was written. Skipping validation does not just risk failure. It changes the cost structure of failure entirely. A founder who validates early and discovers their idea needs reshaping has lost a few weeks and a modest research budget. A founder who skips straight to build and discovers the same thing has lost the entire development budget, the time spent building, and often the appetite to start again. The dating app project we worked on illustrated a narrower version of this problem. The client wanted to skip discovery around the messaging component and focus purely on onboarding. Skipping that one section of discovery meant we built a generic messaging feature that contradicted the entire product premise: a platform focused on verified, human connections that then allowed automated and fake messages. The mismatch required a complete rewrite of the messaging section, at a cost of approximately £15,000 in additional budget and two months of extra work. That was the cost of skipping discovery on one feature. ## 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 ## What Lean Validation Actually Means for App Founders Lean validation is about doing the right research at the right time, and making sure each stage of that research informs a genuine decision rather than decorating one that was already made. The lean part refers to how you sequence it. You start with the cheapest possible way to test the most important assumption. If a founder believes there is a genuine market need for their product, the cheapest way to test that is to run a handful of user interviews or a structured survey with people who fit the target profile and ask them, directly, about the problem the product is meant to solve. > Getting something to market imperfect but testable is always cheaper than building a perfect product nobody asked for. That first step costs very little. It can be done in a week or two. And it can save months of work if the answer is that the problem is either not widely shared, or already well served by existing solutions. What follows is iterative. Each stage of the product, from concept to prototype to early release, gets tested with real users before the next stage of investment is committed. The goal is to enter each phase of spending already knowing what the previous phase confirmed. That is what keeps validation lean, not cutting corners on research, but building the research into the decision-making process so that every pound spent has a foundation under it. Run your first validation test before you brief a developer. A structured survey with 30 to 50 people from your target audience will tell you more about market appetite than a week of competitive research. ## Proving the Problem Exists Beyond Your Own Experience One of the clearest traps in early product thinking is the assumption that a personal experience of a problem is evidence of a market. It is very easy to think: I have this problem, therefore everyone has this problem, and that is simply not the case. A founder's own experience of a problem is a useful signal that the problem might exist more broadly. It is not proof that it does. This matters because building on an unconfirmed assumption about market size is not just risky, it changes the entire shape of what you build. If a founder believes their problem is universal, they design for scale, for a wide user base, for broad feature coverage. If the problem turns out to be niche, the product is the wrong shape for the market it actually has. The practical fix is straightforward: use focus groups or surveys to check that a genuine broader need exists before committing to a build. This does not require a large sample. Talking to 20 or 30 people who fit your target profile will quickly reveal whether the problem lands with others the way it does with you, whether they describe it in the same terms, and whether they have already found ways around it. If they have, those workarounds are important data. They tell you what the product will need to do better than the current alternative to earn a place in someone's life. The property developer who came to us with plans for a concierge app for high-rise properties is a clear example of what good validation at this stage produces. They came in with a suggested budget and a pre-formed idea of what they wanted. We convinced them to undertake a proper discovery phase, including focus groups and user workshops. What emerged was that the product needed to be considerably simpler than envisaged. A number of planned features were dropped entirely. The focus shifted from replacing existing building systems to creating a genuine human connection with the product. The result was a better product at a lower cost, and the discovery phase was what made that possible. ## How to Run Focus Groups and Surveys That Give You Honest Data The quality of validation depends almost entirely on whether you get honest responses. And honest responses are harder to get than they seem, because participants in user research tend to be polite. They tell you what they think you want to hear. They agree that they would use your product. They nod when you describe the problem. None of that is reliable data. #### Designing questions that reveal real behaviour The most useful questions in a focus group are behavioural, not attitudinal. Instead of asking whether someone would use a product, ask what they currently do when they face the problem it is meant to solve. Ask how often that happens. Ask what it costs them in time, money, or frustration. Ask what they have already tried. These questions reveal real behaviour, not hypothetical responses, and [real behaviour is a far better predictor](https://weareaffective.com/learning-centre/how-to-test-a-product-concept-with-behavioural-realism-rather-than-interview-ent) of what someone will actually do when the product exists. The [gap between stated intent and actual behaviour](https://weareaffective.com/learning-centre/what-a-behavioural-concept-test-reveals-that-a-prototype-test-cannot) is significant. Research collected by [AppTweak](https://www.apptweak.com/en/aso-blog/app-market-research) suggests that when users are asked whether they would use an app, 60 to 80 per cent typically respond positively, but actual usage is often only 10 to 20 per cent. This means that enthusiastic responses in a survey are not the same as a confirmed user base. #### Recruiting participants who will challenge you Recruit participants who are likely to be critical users, not cheerleaders. Friends, family, and professional contacts who know the founder tend to soften their feedback. Strangers who genuinely fit the target profile and have no social connection to the founder give you the most useful data. It takes more effort to recruit them, but the quality of what you learn is substantially better. Ask participants to describe what they do today, not what they might do with your product. Behavioural questions reveal real habits. Hypothetical questions reveal politeness. ## When Founders Treat Research as a Box-Ticking Exercise Research has no value if the founder has already decided not to act on it. This sounds obvious, but it is more common than it should be, and it tends to come from founders who have deep industry experience and very strong views about how a product should work. We walked away from one engagement for exactly this reason. The founder had significant experience in their sector and came in with a detailed, fixed idea of what the product needed to be. The research process was agreed to, but it was clear from early on that there was no genuine intention of acting on the findings. When focus groups produced compelling evidence that a large portion of the target user base did not want certain features and actively preferred alternatives, the founder dismissed it. The evidence did not move the brief. We eventually ended the engagement. The product launched roughly a year later, largely unchanged from the original concept, and by our understanding it did not find the audience the founder had assumed was there. The same issues the research had flagged were the reasons it struggled. The purpose of validation is to give you information that is more reliable than your instincts. A founder who treats it as decoration has not validated anything. They have spent time and money producing a document that will not change what they build. ## Testing Onboarding and Core Value Before You Build Onboarding is where most products lose users, and it is almost always underestimated during planning. A founder who has spent months thinking about their product understands it completely. A user who has spent 30 seconds with it understands very little, and if they do not get to something useful quickly, they leave. Testing the onboarding flow with real users before development begins reveals [where comprehension breaks down](https://weareaffective.com/learning-centre/when-users-blame-themselves-for-your-confusing-app-youve-already-lost-them). It shows you which steps feel logical to you but confusing to a new user, where the friction accumulates, and whether users can complete their first meaningful action without help. These are things that cannot be predicted by a founder who already knows the product. They can only be seen by watching someone who does not. The checklist we apply before launch has a small number of non-negotiables, and two of them sit inside onboarding. The core value proposition needs to be visible within the first 60 seconds. And a user must be able to complete their first value-generating action without friction. These are the moments that determine whether someone returns after the first session. Getting them right before the build means not having to rewrite them after, which is always more expensive and time-consuming than doing it in the design phase. Watch at least five people try to use your prototype without any explanation from you. Where they pause, re-read, or click the wrong thing, that is a design problem, not a user problem. ## Scoping the Right Product, Not the Imagined One Founders often arrive with a scope built around everything the product could be, rather than what it needs to be to deliver value on day one. This is partly enthusiasm and partly a belief that a more complete product is more compelling to users. In most cases, the opposite is true. A narrower product with a [clear, well-executed core function](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-) is almost always easier to validate, easier to build, easier to market, and more useful to the first wave of users than a broad product that tries to do many things at once. The question that should drive scoping is not what would be good to include, but what does a user need to get genuine value from this product on their first session. When we worked with the property developer on the concierge app, the discovery process reduced the scope significantly. Features that seemed important in the planning phase turned out to be unnecessary once we understood [what residents actually needed from the product](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one). Removing them did not weaken the product. It made it more focused and more deliverable within the available budget. The scope that emerged from real user research was different from the scope the founder had imagined, and it was better. | Scoping approach | Starting point | Risk | Outcome | | --- | --- | --- | --- | | Imagined scope | Founder's vision of the full product | Over-build, budget overrun, unclear core value | Large product that may not serve real needs | | Research-led scope | What users need on session one | Under-scoping if research is thin | Focused product aligned to confirmed demand | ## The Vanity Product Trap: When Conviction Overrides Evidence There is a pattern we have seen across multiple projects that is worth naming directly, because it tends to unfold in the same way each time. A founder with strong personal conviction in their vision progresses through research, focus groups, and design review, and at each stage they engage with the process on the surface while the underlying product stays fixed. The data does not move them. The feedback does not move them. What emerges is a [product shaped entirely by the founder's preferences](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you) rather than by evidence. We describe this as a vanity product, and we have seen it play out in full on two separate projects: one in fitness and wellbeing, one in grassroots football. On both, we identified the warning signs early: an excessive drive to perfect the product before launch, decisions being rolled back after sign-off to request further changes, and a pattern of prolonged decision-making that was really a way of avoiding a release date. We flagged it in both cases. Both projects ran through their budgets in the design and build phases without ever reaching a fully live product. The question Simon uses to cut through this is direct: are you solving a real problem that people will pay for, or are you in love with the solution? It is a question that filters very quickly. A founder who can answer it honestly has the basis for a real product. A founder who cannot, or who deflects it, is probably building something for themselves. ## Partial Validation and the Gaps That Blow the Budget Partial validation is a particular kind of problem because it feels like validation. A founder tests the concept and gets positive responses, so they feel confident moving forward. But they skip discovery on a specific feature, or they test the onboarding without testing what comes immediately after it, and those untested sections are where the expensive surprises live. The dating app project is the clearest example we have of this. The product was built around verified, human connections. Onboarding was tested carefully. But the messaging component was skipped because the client wanted to focus resources on what they saw as the more distinctive part of the product. The result was a messaging system that contradicted the entire product premise: verified profiles leading to automated, fake messages. The mismatch was fundamental. Rebuilding that section cost approximately £15,000 in additional budget and added two months to the timeline. The discovery that was skipped would have cost a fraction of that. #### Where partial validation most often breaks down The sections most often skipped are the ones that feel generic or secondary to the founder's core vision. Messaging, notifications, settings, and user account management tend to get less scrutiny because they are less exciting. But they are the parts users interact with constantly, and they carry the product's tone and experience into every session. A gap in validation here is rarely a cosmetic problem. 1. Define every section of the product that a user will interact with, not just the hero features. 2. Assign each section a validation status before build begins. 3. Treat any untested section as a budget risk, and price it accordingly. ## What a Pre-Launch Validation Checklist Should Actually Cover A validation checklist is only useful if it covers the things that actually determine whether a product succeeds in market. The five areas we treat as non-negotiable before any product goes live are built around the user's experience of the product, not the founder's confidence in it. The first is confirmed user need beyond the founder's own experience, tested through focus groups or surveys with real potential users. The second is a tested onboarding flow, checked with real users for comprehension and friction, not reviewed by the team who built it. The third is a clear value proposition visible within the first 60 seconds, because users make their keep-or-delete decision very quickly. The fourth is the ability to complete a first meaningful action without friction, which is the moment a product proves its core promise. The fifth is avoiding overwhelming users too early, which is a particular risk for products with complex functionality. #### Secondary checks that often get missed Beyond those five, there are areas that get reviewed less rigorously but carry real weight in whether users discover and engage with the product. App store copy and screenshots are the first thing a potential user sees before they download anything. Product framing determines whether the value proposition is understood from the outside. Safety features, where relevant, need to be part of the pre-launch check rather than a post-launch addition. The checklist is a structured way of making sure that the decisions most likely to determine early traction have been made intentionally and tested with real users, rather than assumed in a planning meeting. ## Getting an Imperfect Product to Market Over a Perfect Product Nowhere There is a version of the validation process that loops indefinitely. The founder tests, finds things to improve, improves them, tests again, finds more things to improve, and never reaches a point where the product feels ready to launch. This is avoidance dressed as thoroughness, and it is one of the most common ways a product runs out of budget before it reaches a user. Getting something imperfect to market quickly and iterating is consistently cheaper and more effective than attempting to build a perfect product from the start. The trading card platform client we worked with ran into a version of this on the funding side. He was struggling to get traction with pitch decks alone, so he made the decision to build as far as he could with a working, if rough, version of the product. That demonstrable product changed his conversations with investors. They could see how it worked. They could interact with it. A functional prototype told investors more than a slide deck ever could, because it proved the idea was buildable. The same principle applies to the launch decision. A product that is live, even at 80 per cent of the founder's vision, can gather real usage data, real feedback, and real signals about what the market actually values. That information is more useful than another month of internal iteration, and it informs the next phase of build in a way that no amount of planning-table discussion can match. Spending budget on iteration before launch only makes sense if the resources are substantial. For most founders, launching and listening is a far better use of the available investment. ## Conclusion Validation is the mechanism that determines whether the real work is worth doing at all. A founder who skips it, or runs through it without genuine intent to act on what they find, has not saved time. They have borrowed it, and the interest is paid in budget overruns, rewrites, and products that reach a market that was never there. The stories in this piece are all variations on the same decision point. The dating app founder who skipped one section of discovery and paid £15,000 to fix it. The fitness and football founders who spent everything on design and build and never launched. The property developer who came in with a fixed idea and left with a better, simpler product because they agreed to a proper discovery phase. The pattern across all of them is consistent: the founders who treated validation as a genuine input into what they built came out better, at lower cost, with a product that had a real foundation under it. The question to ask before any build commitment is whether you are solving a real problem that people will pay for, or whether you are in love with the solution. If you are not sure of the answer, that uncertainty is exactly what validation exists to resolve. [Start the conversation about your product](https://weareaffective.com/get-started) ## Frequently Asked Questions What is lean validation and why does it matter for app founders? Lean validation is the process of testing your app idea with real users before committing to development, allowing you to confirm whether a genuine market demand exists. It helps founders discover early whether they have a viable business or simply a personal project, which can look identical from the inside but very different from the outside. When should validation take place in the app development process? Validation should happen before a development contract is signed, not after. Treating it as a decision point rather than a phase means you avoid spending serious money on an idea that has not yet been tested with real people. Why do so many founders skip validation or approach it in the wrong way? Many founders arrive at the validation stage having already decided the answer, meaning they seek confirmation rather than honest information. This leads them to structure their research in ways that support existing beliefs, rather than genuinely testing whether the idea holds up. Is competitive mapping a reliable substitute for proper user research? No, competitive mapping can feel like productive progress but it cannot replace conversations with prospective users. A spreadsheet cannot tell you that users would not choose your product, or that the problem you are solving does not feel like a real problem to them. How common is it for apps to fail because of poor validation? According to Business of Apps, 42 per cent of apps fail because they were launched without prior market research. These are not products that ran out of funding or were technically flawed. They are products that nobody wanted, and that problem could have been identified before any code was written. What is the difference between solving a real problem and being in love with a solution? Solving a real problem means users recognise a genuine pain point and are willing to pay for something that addresses it. Being in love with a solution means a founder has built a clear vision around a product that may not correspond to any real or pressing need in the market. Does taking time to validate an idea slow down the overall development process? Validation does slow things down at the start, but skipping it is almost always slower and more expensive overall. Building a product that nobody wants and then having to change direction or start again costs far more in time and money than early testing would have done. What should a founder do if users respond negatively during validation? Negative responses during validation are valuable information, not a setback. They reveal whether the problem being solved is real, whether users prefer existing alternatives, and whether the core premise of the product needs rethinking before any significant investment is made. ## 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.