--- title: How Can I Conduct a Mobile App Feasibility Study? description: Learn how to conduct a mobile app feasibility study that tests desirability, technical fit and commercial viability before you commit to building anything. image: https://weareaffective.com/hubfs/learning-centre-images/how-can-i-conduct-a-mobile-app-feasibility-study.webp --- [Skip to content](https://weareaffective.com/learning-centre/how-can-i-conduct-a-mobile-app-feasibility-study#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 Can I Conduct a Mobile App Feasibility Study? Table of Contents A pre-launch founder in the football industry came to us with a colour-coded spreadsheet. It mapped out every competitor product in his category, feature by feature, and his plan was to merge several of them into one app. He was visibly excited and pleased with himself, and the spreadsheet was good work. Then we started asking about the people who'd actually use it. Why does someone pick an all-in-one product over three specialised apps they already like? Does merging five things risk dumbing down all five? He deflated. That conversation, and the gap it exposed, is what a mobile app feasibility study is for. > A spreadsheet of competitor features can't tell you whether anybody wants your app. It's our job to be honest about what makes a product succeed, because building on a founder's enthusiasm alone doesn't serve anyone. Feature maps feel like progress and they're cheap. They also can't contradict you, which is part of the appeal. This piece walks through how we run feasibility work, what it answers, how long it takes, what it costs, and how to spot the version that's quietly designed to agree with you. We've included real projects, including the ones where the honest answer was no, and the one where skipping a chunk of discovery cost a client £15,000 and two months. ## What a Mobile App Feasibility Study Actually Answers A mobile app feasibility study answers one question in five parts. Should you build this, and if you should, [what exactly do you build, for whom](https://weareaffective.com/app-planning-strategy), on what money, and what stops you? - Desirability. Do real people want this enough to change what they already do? - Behavioural fit. Does an app suit how they solve the problem today? - Technical viability. Can it be built well on the devices your users own? - Commercial sense. Do the numbers work in year two, not just at launch? - Operational reality. Who runs it, supports it, and keeps it legal? Most studies we're asked to quote for only want the third one. The client has decided the app is wanted and needed, and what they want from us is a build estimate with [a research cover page](https://weareaffective.com/learning-centre/how-to-scope-a-pre-build-research-phase-when-the-budget-is-already-signed-off-fo). That's a technical scope, and a technical scope answers can we, never should we. The cost of skipping the other four shows up after launch, when the app works perfectly and nobody opens it twice. [Business of Apps](https://www.businessofapps.com/insights/top-reasons-why-mobile-apps-fail-to-make-a-mark-in-the-market/#:~:text=As%20surprising%20it%20may%20sound,%20three%20days%20of%20its%20installation) puts 42 per cent of app failures down to launching without prior market research, which matches what we see in the briefs that arrive already half-built. ## Defining the Question Before You Start Researching Before any fieldwork, we write down the decision the study has to serve. Not the topic. The decision. "Do we build a companion app for the loyalty scheme, or extend the mobile site?" is a decision. "Understand our customers better" isn't, and research pointed at it produces a document nobody can act on. Then we take a step back and ask what need the product fills, how people are meeting that need right now without it, and, the part that gets skipped, how they feel about doing it that way. If people are reasonably content with a manual process, there's no reason to build a technical one. A skincare customer who's happy writing her routine on a Post-it doesn't need an app for it. The opening is where the current process is failing people emotionally, not just functionally. #### Write the question you'd hate to get wrong We also ask what finding will change the plan. If no answer changes anything, the research is decoration and we say so before anyone spends money on recruitment. Write the decision in one sentence and stick it at the top of the research plan. Every session, survey and technical spike after that has to earn its place against that sentence. ## 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 ## Testing Desirability: Does Anyone Actually Want This? We worked on a product aimed at African communities living abroad, built to help people stay connected to their home communities. Technically it was straightforward and we were confident we could deliver it well. We ran a lot of focus groups with the target market, and the finding was plain. There wasn't enough desire for that kind of product. Nobody wanted it badly enough to make it part of their week. That's a hard thing to hear and a cheap thing to learn at that stage. The alternative was a finished app, a launch, and a very quiet analytics dashboard. > Asking people if they'd use your app measures politeness, not demand. Direct questions reward you with agreement. [AppTweak](https://www.apptweak.com/en/aso-blog/app-market-research) describes the familiar pattern, where 60 to 80 per cent of people say yes when asked whether they'd use an app and only 10 to 20 per cent go on to use it. #### Better questions than "would you use this?" We ask what people did last time the problem came up, what they tried, what it cost them in time or money, and what they'd give up to make it go away. Past behaviour is checkable. Stated intent isn't. ## Behavioural Fit: How People Solve the Problem Today During the focus groups we ran for a property developer's concierge app, we deliberately included groups of people living in social housing. They weren't the target market for a high-rise concierge product at all. We wanted a read on how community actually forms between neighbours. What we found is that they were having meaningful conversations with each other. Not superficial exchanges about bin days, but deeper connections, and that depth was what fostered the sense of community the developer said they wanted to create. That changed our recommendation completely. Instead of pushing every interaction into the app and removing the human conversation, we advised that the app should take the mundane and transactional work. Maintenance requests, fire drill procedures, where the recycling goes. Everything else should actively push residents towards talking to the concierge and to each other. Behavioural fit asks where an app genuinely helps and where it quietly takes something away. A product can absorb a task perfectly and still make the experience worse, because the task was carrying something else. Food delivery did this to the phone call to the local restaurant, and some brands have spent years trying to rebuild the warmth they removed. ## Technical Feasibility and the Devices Your Users Really Own On that same product for African communities abroad, the second finding sat underneath the first. A meaningful share of the people on the other end of those connections were using devices with very limited capability at the time. Delivering even half of the intended experience on those handsets was going to be extremely challenging. The product wasn't just unwanted, it was aimed at a device landscape that couldn't carry it. Technical feasibility gets treated as a question about your engineering team. It's really a question about your users' pockets. The relevant checks are concrete. 1. Pull real device and OS data from your website analytics rather than assuming current flagship phones. 2. Test the heaviest screens on the cheapest handset in your actual user base. 3. Check network conditions and what the app does when the connection drops. 4. List every permission you need, and what happens to the experience when someone says no. 5. Confirm which third party services you depend on and what their failure does to you. Permissions deserve particular attention. An app that demands location, contacts and notifications in the first thirty seconds loses people who'd otherwise have stayed. Before you commission any technical work, spend an afternoon with your own web analytics. The device mix sitting in there is usually older and more varied than anyone in the room expects. ## Commercial Feasibility: Costs, Revenue and the Honest Numbers The property developer came to us with a budget already suggested and a fairly fixed idea of what they wanted. What they were really after was a validation of that idea rather than a proper scoping exercise. We talked them into a full discovery phase instead, with focus groups and user workshops. What we found was that the product needed to be a lot simpler than they'd envisaged. A long list of planned features never made it into the build, and the focus moved to creating a human connection with the product rather than replacing systems the building already ran perfectly well. They got a better product for less money. That's the commercial case for feasibility work in one project. It doesn't only tell you whether to spend, it usually tells you to spend less. #### The numbers people forget Build cost is the number everyone has. The ones that sink products are the running costs. App store fees, server and service bills that scale with usage, the two annual OS updates you have to support whether or not you've added a feature, customer support, content, and the cost of getting each new user through the door. Work out how many active users you need to stand still. If that number makes you wince, the feasibility question has answered itself. ## Operational, Legal and Compliance Checks We worked on a [social product for fitness](https://weareaffective.com/learning-centre/what-a-fitness-social-app-changed-when-it-realised-precise-location-was-the-wron) where the whole concept was map based. You'd see other users' real-time locations and arrange to meet for a shared workout. The research showed that a high proportion of participants were going to be female, and security stopped being a footnote. We redesigned the feature from the ground up. [Locations got a randomised offset](https://weareaffective.com/learning-centre/what-a-fitness-social-app-changed-when-it-realised-precise-location-was-the-wron), so you only saw the vague area someone was in. People could talk, look at each other's profiles, and then choose to share an exact location. The core value survived, because you still had enough proximity data to judge whether meeting up made sense. > A feature can be technically simple and still be operationally unsafe. Feasibility also has to cover the unglamorous operational load. Who answers support messages at the weekend, who moderates user content, who updates the legal copy, and who's accountable when something goes wrong. Then the compliance layer. How you handle personal data and consent, age verification where it applies, accessibility, the app store review rules for your category, and any sector rules that bite. Wellness and supplements brands in particular find that health claims and advice features carry obligations the marketing team never had to think about. ## The Danger of Partial Discovery On a dating app project built around verified profiles and keeping bots out, the client wanted to skip discovery for the messaging side and put everything into the onboarding process. We understood the logic. Onboarding was the differentiator and the budget was finite. What we ended up building for messaging was generic, because nothing had told us it shouldn't be. That generic messaging allowed automated messages and fake messages, the exact behaviour the entire onboarding flow existed to prevent. All that emphasis on validation and verification didn't stack up with the rest of the product. The messaging section had to be rewritten, at roughly £15,000 of additional budget and about two months of extra work. Products are interconnected, and discovery on one component tells you things about the components next to it. Skip a part and you don't get a gap in your knowledge, you get a contradiction built into the thing you ship. Users feel that contradiction long before they can name it. [Devtimate](https://devtimate.com/glossary/discovery-phase/) puts [projects that skip the discovery phase](https://weareaffective.com/learning-centre/how-to-scope-a-pre-build-research-phase-when-the-budget-is-already-signed-off-fo) at three to five times more likely to fail or overrun their budget. Our own version of that figure is more specific and arrived as an invoice. ## Research You Have No Intention of Acting On One founder we worked with had deep industry experience and very, very strong opinions about how their product should work. The research ran, and it ran properly. We showed compelling evidence that large numbers of their potential user base didn't want particular features and preferred something else entirely. They didn't move. It became clear the whole thing was a box-ticking exercise, something to wave at a board or an investor, and no finding was ever going to change the plan. We walked away from the engagement. They launched roughly a year later with the product they'd always wanted, and as far as we can tell it went nowhere, for the reasons the research had flagged. This is why we now ask, early and directly, what the study's allowed to change. If the answer is "the colours and the copy", everyone saves money by admitting it. Before fieldwork starts, write down two or three findings that would stop the project. If you can't name a single result that changes your mind, you're buying reassurance rather than research. Underneath the box-ticking there's usually a fear, and it's a reasonable one. User testing can reveal that the idea's wrong, or that nobody wants it. Competitor spreadsheets never do that, which is exactly why founders reach for them. ## How Long a Feasibility Study Takes The honest answer depends on how many distinct groups of people you need to hear from and how hard they are to reach. Everything else moves around the edges. | Study type | Typical span | What's in it | | --- | --- | --- | | Focused check | 2 to 3 weeks | One user group, desk research, a technical review, a go or no-go call | | Full study | 4 to 6 weeks | Two or three user groups, focus groups or interviews, prototype testing, costed scope | | Complex or regulated | 8 weeks plus | Multiple markets, hardware or integrations, compliance review, workshops | Four things stretch a timeline more than anything else. Recruitment is the big one, because hard-to-reach audiences take time to find and incentivise. Then stakeholder availability, since a two-week delay getting the right people into a workshop is a two-week delay to everything. Technical unknowns that need a proper spike add time. So does any audience in another country or language. Running a study faster than this is possible and it costs you depth. The one thing we'd resist compressing is the gap between fieldwork and recommendations, because that's where patterns across sessions surface. Rushing straight from the last interview to the deck gives you a transcript summary rather than a decision. ## What a Feasibility Study Costs and How to Budget for It Price the study against the cost of being wrong. The dating app rewrite was about £15,000 and two months, and that was one component of one product on a project where discovery was otherwise good. A full build taken in the wrong direction costs a multiple of that, and the money's gone before anyone notices. > Feasibility work is cheap compared with building the wrong thing beautifully and on time. Four budget models come up, and they suit different situations. | Model | How it works | When it fits | | --- | --- | --- | | Fixed fee | Agreed scope, agreed price | Clear question, known audience, board needs certainty | | Stage gated | Phases priced separately, decision at each gate | Early ideas where phase one can end the project | | Time and materials | Day rate against an agreed cap | Messy problems where the scope shifts as you learn | | Share of build budget | A set slice of the planned build carved out first | Funded projects with a build number already approved | Stage gating is the one we recommend most often for pre-launch founders. It makes stopping a normal outcome rather than an embarrassment, and it keeps the money in your pocket when phase one says no. Whichever model you pick, put recruitment and participant incentives in the budget as their own line. Underfunding that is how studies end up talking to whoever was easy to find. ## What Investors Want to See in a Feasibility Study Investors have read plenty of decks claiming a huge market and no competition. What earns attention is evidence that you went looking for the reasons this fails and wrote down what you found. The things they want are fairly consistent. Evidence of demand based on what people currently do rather than what they said they'd do. A clear description of who the user is and who they aren't. Named risks, with the mitigation for each. A costed build and a running cost, so the ask has arithmetic behind it. The unknowns you haven't resolved yet, stated plainly. That last one does more work than people expect. A founder who lists three open questions reads as someone who understands their own product. A founder with no open questions reads as someone who hasn't checked. It helps to remember what the audience already believes. Fyresite's own estimate, drawn from industry interviews and their internal experience rather than a peer-reviewed study, puts consumer app success at around [0.5 per cent](https://www.fyresite.com/how-many-apps-fail/). Whatever the precise number, every investor you meet is starting from the assumption that this probably doesn't work. A study that names the risks is arguing in the same language they're already thinking in. ## Turning Findings Into Decisions: Cut, Keep or Kill Research only pays for itself at the debrief. We run it in a set order, because the order stops the loudest voice in the room setting the agenda. 1. Restate what was tested and what the research set out to achieve, whether that was exploring features, validating a direction, or something else. 2. Review the profiles of the people who took part, so their feedback can be weighted properly. Not every user matters equally to every feature. 3. Map the business value of each feature against its likely uptake. 4. Put everything through an effort versus impact matrix. 5. Agree what gets built next, what waits, and what gets dropped entirely. Dropped entirely is the category teams struggle with. On the concierge app, a good number of features the developer had arrived with never made it past that stage, and the product was better and cheaper for it. Cutting isn't failure, it's the study doing the job you paid for. The weighting step matters more than it sounds. Five enthusiastic responses from people who match your core user carry more weight than twenty from people who downloaded something similar once. Write the kill list into the output document with reasons attached. Six months on, somebody will suggest a dropped feature again, and the note saves you running the argument twice. ## Signs Your Feasibility Study Is Only Validating What You Already Believe When somebody tells us a product feels unintuitive, our first question is where that idea comes from. Is it a feeling from the people in the room, is it concrete analytics data, or is it user research? Each one carries a different risk. Room opinion needs checking for insider bias, because people who know a product deeply find flows obvious that a first-time user finds baffling. Analytics need checking for correct interpretation before anyone acts on them. The same test applies to a feasibility study. Here's what suggests yours is agreeing with you. - Every participant was recruited through your own network or existing customers. - The questions describe your solution before asking about the problem. - No session has produced a finding that annoyed anyone. - The competitor analysis is thorough and the user research is thin. - Nobody can name a result that stops the project. That fourth one is the football spreadsheet again. Competitive feature mapping gives immediate validation of opinions you already hold, it's tangible, and it's far cheaper than testing with users. Nothing in a spreadsheet has ever told a founder their idea is wrong. ## Conclusion A mobile app feasibility study is worth doing when you're prepared to be told no. The property developer who let us run proper discovery got a simpler product for less money. The client who skipped discovery on messaging paid £15,000 and two months to put it back. The founder who treated research as a box-ticking exercise launched exactly what they'd always planned and it went nowhere. The work itself isn't complicated. Write down the decision you're making. Find out how people meet this need today and how they feel about doing it that way. Test desirability against behaviour rather than stated intent. Check the devices your actual users hold. Do the running cost arithmetic, cover the operational and legal load, and run discovery across the whole product rather than the parts that interest you most. Then act on what comes back, including the parts you didn't want. A study that only confirms your plan has cost you money and taught you nothing. If you're weighing up an app idea and you'd rather find the problems now than after launch, [let's talk about your feasibility study](https://weareaffective.com/get-started). ## Frequently Asked Questions What exactly does a mobile app feasibility study answer? It answers whether you should build the app at all, and if so, what you build, for whom, on what budget, and what might stop you. In practice that breaks into five parts: desirability, behavioural fit, technical viability, commercial sense and operational reality. How is a feasibility study different from a technical scope? A technical scope answers "can we build this?" and usually assumes the app is already wanted. A feasibility study asks "should we build this?" first, testing demand, user behaviour and the commercial case before anyone estimates a build. Isn't a competitor feature comparison enough to validate my idea? No. A feature map tells you what other products do, but it cannot tell you whether anyone wants yours, or why they would switch from tools they already like. It also never contradicts you, which is part of why it feels so reassuring. How do I frame the question my study needs to answer? Write down the decision, not the topic. "Do we build a companion app for the loyalty scheme or extend the mobile site?" is a decision you can act on, whereas "understand our customers better" produces a document that sits on a shelf. Why does it matter how people solve the problem today? Because if people are reasonably content with their current workaround, there is no real opening for your product. The opportunity sits where the existing process is failing people emotionally, not just functionally, so ask how they feel about doing it the current way. What happens if I skip the non-technical parts of the study? The cost usually appears after launch, when the app works perfectly and nobody opens it a second time. Business of Apps attributes 42 per cent of app failures to launching without prior market research, which matches the half-built briefs we regularly see. How can I tell if a feasibility study is just designed to agree with me? Look at whether the work is genuinely capable of returning a "no". If the scope only covers technical build estimates with a research cover page, or if no finding could realistically change your plan, it is validation theatre rather than feasibility work. Can a feasibility study really conclude that I shouldn't build the app? Yes, and a study that cannot reach that conclusion is not worth paying for. We have delivered honest "no" answers on real projects, and we have also seen a client skip part of discovery and lose £15,000 and two months as a result. ## Related Articles [![How to Translate a Retention Problem Into Language a Board Will Act On](https://weareaffective.com/hubfs/learning-centre-images/how-to-translate-a-retention-problem-into-language-a-board-will-act-on.webp)](https://weareaffective.com/learning-centre/how-to-translate-a-retention-problem-into-language-a-board-will-act-on) ### [How to Translate a Retention Problem Into Language a Board Will Act On](https://weareaffective.com/learning-centre/how-to-translate-a-retention-problem-into-language-a-board-will-act-on) A product team can walk into a board meeting with the retention problem fully mapped and walk out... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![How do you set up effective development team communication?](https://weareaffective.com/hubfs/learning-centre-images/how-do-you-set-up-effective-development-team-communication.webp)](https://weareaffective.com/learning-centre/how-do-you-set-up-effective-development-team-communication) ### [How do you set up effective development team communication?](https://weareaffective.com/learning-centre/how-do-you-set-up-effective-development-team-communication) Poor communication between design, product, and development rarely looks like a shouting match. It... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![5 Most Common Mistakes Companies Make When Developing a Branded App](https://weareaffective.com/hubfs/learning-centre-images/5-most-common-mistakes-companies-make-when-developing-a-branded-app.webp)](https://weareaffective.com/learning-centre/5-most-common-mistakes-companies-make-when-developing-a-branded-app) ### [5 Most Common Mistakes Companies Make When Developing a Branded App](https://weareaffective.com/learning-centre/5-most-common-mistakes-companies-make-when-developing-a-branded-app) Most branded apps fail quietly. There is no dramatic crash, no angry press release, just a slow... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![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.