--- title: App Feasibility Analysis the Framework for Gono Go Decisions description: Learn what app feasibility analysis actually tests, from demand and technical risk to business model and scope, before you commit budget to building. image: https://weareaffective.com/hubfs/learning-centre-images/app-feasibility-analysis-the-framework-for-gono-go-decisions.webp --- [Skip to content](https://weareaffective.com/learning-centre/app-feasibility-analysis-the-framework-for-gono-go-decisions#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 Feasibility Analysis the Framework for Gono Go Decisions Table of Contents We worked on a sports club app with real money behind it. One product to handle finances, games, schedules and players across several different sports. It [never reached the app store](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi). The budget went on feature after feature after feature, the client and ourselves parted ways, and nothing was published. An app feasibility analysis, run honestly before anyone opens a design file, is what gives a project the chance to avoid that ending. > The cheapest version of a no-go decision is the one you make before anyone writes code. Feasibility work gets treated as a delay. Founders have usually lived with the idea for a year or two, they can see the finished thing in their head, and a few weeks of questions feels like someone slowing them down on purpose. What it really does is move the hard conversations to the point where they're cheap, because every one of them gets louder and more expensive as the build goes on. What follows is how we test an idea before we agree to build it. Demand, devices, rules, money, scope, and whether the people paying for it are ready to make decisions. Some of these projects passed. Some didn't, and the ones that didn't are the more useful stories. ## What an App Feasibility Analysis Actually Tests Most app failures have four layers underneath them, and they sit on top of each other in a particular order. Get the first one wrong and nothing above it can save you. 1. Market need. Is there a real appetite for this, outside the people who already agree with you? 2. Business model. Does the money work at the volumes you can realistically reach? 3. Timing. Is now the moment, given devices, habits and what else exists? 4. Execution. Can the product be built, shipped and understood? #### Where an app feasibility analysis starts It starts at the top of that list, because a weak result in layer one makes the other three academic. Poor UX gets blamed for a lot of dead products. Quite often the interface was a symptom and the real problem was that nobody needed the thing. You have to look at both together, which is why [we don't separate research from design](https://weareaffective.com/learning-centre/what-mobile-app-design-and-development-services-does-your-business-actually-need). The question we keep returning to is what need the product fills, and how people are meeting that need today without it. Then, and this is the part teams skip, how do they feel about doing it that way? Someone grumbling about a spreadsheet every Sunday night is a market. Someone who's perfectly content with the spreadsheet is not. ## Evidence of Demand Beyond the Founder's Hunch We worked on a product aimed at African communities living abroad, built to help people keep a connection with their home communities. The idea was warm, the founder believed in it, and the build itself was straightforward. We ran a series of focus groups with the target market and the answer came back flat. There wasn't enough desire for that kind of product. People were already staying in touch in ways that suited them. That finding cost a fraction of a build and saved the whole thing. It's also the most common killer going. Of 101 startup post-mortems analysed by [CB Insights](https://rightidea.app/blog/startup-idea-validation), 42% of failed founders put "no market need" at the top of the list. Validated need means evidence from outside your own experience. Focus groups, surveys, interviews with people who have no reason to be kind to you. Friends and former colleagues will tell you the idea is good, because they like you and the question sounds rhetorical. Ask people what they did last time they had this problem, not whether they'd use your app. Past behaviour is evidence. A yes to a hypothetical is politeness. If the honest answer to "[should I build an app](https://weareaffective.com/learning-centre/how-can-you-validate-your-app-idea-without-writing-a-single-line-of-code)" is that people are managing fine without one, the useful outcome of your research is a no, delivered early and cheaply. ## 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 ## Technical Feasibility: Devices, Platforms and Infrastructure The same product aimed at African communities carried a second problem, and it had nothing to do with appetite. The devices commonly used in several of the countries involved had very limited capability at that time. Delivering even half of the intended experience on those phones was going to be a serious undertaking. The code was fine. The hardware in people's hands wasn't. Technical feasibility rarely means "can this be built". Almost anything can be built. It means asking what it runs on, who maintains it, what it depends on that you don't control, and what happens at volume. > A product can be technically straightforward and still be impossible on the phones people own. So the questions worth asking early are practical ones. What's the actual device mix of your audience, not the national average? Which platform carries your first users, and can you launch on one? What third-party services are you leaning on, and what's your position if one of them changes its pricing or disappears? How much of the experience depends on a good connection? Answer those before design starts and the build gets simpler. Answer them after and you're rewriting things that already work in the studio and fall over in a kitchen in Lagos or on a train through Kent. ## Regulation, Compliance and App Store Risk We built a peer-to-peer currency exchange product where travellers with leftover foreign cash could swap it with other travellers at interbank rates, skipping the commission. The core transfer mechanism worked well. What we hadn't factored in was anti-money laundering. Apple looked at unlimited transfers between parties and saw a vehicle for laundering money, and they weren't wrong to. We went back and retrofitted several layers. More stringent know your customer checks, tighter transfer security, and a hard cap on how many transfers any two people could make between them. All of it was doable. All of it cost more after the fact than it had before. Compliance is also a budget item, and a big one. Highly regulated categories can push development costs up by 30 to 50% because of security, compliance and data protection work, according to [GoodFirms](https://www.goodfirms.co/resources/cost-to-develop-an-app). That money has to be in the plan from the start. Read the App Store review guidelines against your actual feature list during feasibility, not during submission. Apple's objection to our currency product was predictable from the guidelines alone. The reviewer is assessing what a determined bad actor does with the features you've shipped, and your app feasibility study should do the same. ## The Commercial Case: Business Model, Pricing and Timing A sound business model survives contact with real numbers at realistic volumes. Plenty of app ideas work beautifully at a million users and lose money at ten thousand, which is the number most products actually reach in year one. On the dating product we worked on, the entire commercial premise rested on verified profiles and keeping bots out. People were being asked to choose it over free alternatives because the people on it were real. That's a clear reason for someone to pay, and it also sets a standard the rest of the product has to meet. The commercial questions we press on during feasibility are fairly blunt. - Who pays, and are they the same person as the user? - What does it cost you to serve one active user for a year? - How many users do you need before the model stops losing money? - What's the reason someone pays again in month three? Timing sits alongside all of it. The same product launched two years apart performs differently, because the devices change, the habits change and the competition changes. Our African communities product was partly a timing story. The appetite wasn't there and neither was the hardware, and both of those are facts about a moment rather than facts about the idea. ## Scope, Runway and the Case for Launching Small Back to the sports club app. We [advised an incremental release from the very start](https://weareaffective.com/learning-centre/how-to-build-an-incremental-release-plan-a-founder-will-actually-agree-to). Launch with a single sport. Launch on a single platform. Build an MVP, get it in front of real clubs, learn, then widen. The client pushed back on all of it, right through the process. They wanted everything, and they didn't want to go to market until everything was ready. We warned them early that the budget was going to get wildly out of control, and that they risked running out of money with a product still not ready to launch. The warning was noted and the features kept coming. That's exactly how it ended. Entire budget gone, nothing on the store, and the relationship over. Runway is the constraint that makes every other decision for you. Scope expands quietly, one reasonable-sounding request at a time, and each one feels small against a budget that still looks healthy on the spreadsheet. Write down the single thing your app must do for a user to come back, then treat every other feature as a candidate for version two. Most of them stay there. Working with the process matters as much as the plan itself. A project that resists iteration and incremental release is at real risk of never launching anything at all. ## Why Partial Discovery Is Not Discovery On that dating app, the client decided to skip discovery for the messaging side and put the whole research budget into onboarding. Onboarding was the hard bit, the thinking went, and messaging is messaging. Everyone knows what a chat screen looks like. What we built was a generic messaging feature, and it quietly contradicted the entire product. It allowed automated messages and fake messages, the precise things the verification work in onboarding existed to prevent. A user went through a rigorous check to prove they were real, then landed in an inbox that made no such demand of anyone. > Discovery on half a product buys you half a product that works. The whole messaging section had to be rewritten. Roughly £15,000 of extra budget and about two months of extra work, spent recovering a position we were already in before the shortcut. Discovery pays for itself in avoided rework, which is hard to feel because you never see the invoice you didn't get. [Nielsen Norman Group](https://www.nngroup.com/articles/discoveries-in-industry-revealed/) puts the reduction in project failure risk from proper discovery at 75%. The £15,000 is the version of that number you can hold in your hand. ## Is Your Side Ready to Make Decisions? Feasibility covers whether the people funding the product can agree with each other under pressure. We worked on a fitness and wellness product with two co-founders who were new to app development. The pattern repeated. We'd get sign-off on a design, start building, and then they'd walk the approval back, saying they hadn't understood that was what we'd actually build. There was no consensus between the two of them, and the approvals seemed to be given out of politeness rather than as real decisions. We kept warning them that the budget was going on design iterations that made no material difference to the product. That fell on deaf ears. The work finished in the design and research stage because the money ran out, and nothing was ever built. So the governance questions belong in the feasibility conversation alongside the technical ones. 1. Who holds the final decision when the founders disagree? 2. What does sign-off mean here, and what does it commit you to? 3. Who can approve a change that adds two weeks? 4. How fast can you give an answer when the build is waiting on one? ## When Feasibility Shrinks the Product Rather Than Killing It A property developer came to us wanting a concierge app for their high-rise properties. They arrived with a suggested budget and a fully formed idea of what they wanted, and what they were really after was a validation rather than a [proper scoping](https://weareaffective.com/learning-centre/how-to-scope-a-pre-build-research-phase-when-the-budget-is-already-signed-off-fo). 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 imagined. A good number of the features on their list didn't go in. The building already had systems running the things those features were going to duplicate, and residents had no appetite for a second place to do the same jobs. We focused instead on creating a human connection with the product. They got a better product and they paid less for it. That's the outcome feasibility produces more often than a flat no, and it's the one founders don't expect when they're braced for someone to tell them the idea is dead. Shrinking is also the kindest result for the roadmap. A smaller launch gets to real users sooner, and real users tell you which of the dropped features actually mattered. Guessing at that from a workshop is a poor substitute for watching someone fail to find something. ## Scoring the Evidence: Go, No-Go and Conditional Go Three outcomes come out of a feasibility process, and the middle one does most of the work. | Outcome | What the evidence looks like | What happens next | | --- | --- | --- | | Go | Need confirmed outside the founder's circle, devices and rules understood, money adds up at realistic volumes | Build the smallest version that delivers the core value, on one platform | | Conditional go | Demand holds, but one area is unproven, such as compliance, a device base or a pricing model | Run a short, focused piece of work on that area before committing the full budget | | No-go | People are content with how they solve this today, or the market has already moved | Stop, and put the money behind something with evidence under it | The same scoring works on products that already exist. A product with a sound value proposition backed by good data, where users understand it and want it and the trouble is [friction or confusion in the flows](https://weareaffective.com/learning-centre/when-users-blame-themselves-for-your-confusing-app-youve-already-lost-them), is a strong candidate for redesign. The signals pointing the other way are repeated pivots with no improvement in retention, and users churning before they ever reach the core feature. When that's the picture, a redesign is paint on a problem that lives somewhere else. ## Conclusion Every story here cost somebody something. The sports club app cost an entire budget and produced nothing on the store. The dating app's skipped discovery cost £15,000 and two months. The currency exchange cost a retrofit of KYC checks and transfer limits that could have been designed in from day one. The fitness product cost two founders their whole development fund in design iterations nobody could commit to. The two that went well look quieter from the outside. A product for African communities that we didn't build, because the focus groups said the desire wasn't there and the devices couldn't carry it. A concierge app for high-rise properties that came in smaller, simpler and cheaper than the brief, and better for it. That's what a good app feasibility analysis buys. Not certainty, because nobody sells that. It buys you the chance to find out what's wrong while changing your mind is still cheap, and the evidence to go ahead with confidence when the answer is yes. [If you're sitting with an idea](https://weareaffective.com/app-planning-strategy) and you'd rather test it than hope, [let's talk about your app feasibility analysis](https://weareaffective.com/get-started). ## Frequently Asked Questions What is an app feasibility analysis? It's a structured test of an app idea carried out before any design or development work begins. It looks at market need, the business model, timing and whether the product can realistically be built, shipped and understood. The output is a go or no-go decision made while changing course is still cheap. Isn't feasibility work just a delay to the project? It feels that way, particularly to founders who have lived with an idea for a year or two and can already picture the finished product. In practice it moves the difficult conversations forward to the point where they cost very little, because those same questions get louder and far more expensive once the build is underway. What are the four layers a feasibility analysis works through? Market need, business model, timing and execution, in that order. They stack on top of each other, so a weak result on market need makes everything above it academic. That's why the process always starts at the top rather than with the build. Why is market need tested first? Because a product nobody needs cannot be rescued by a good interface or a clever business model. Poor UX takes the blame for a lot of dead apps when the real issue was that the demand was never there. Of 101 startup post-mortems analysed by CB Insights, 42% of failed founders cited no market need as the main cause. What counts as real evidence of demand? Evidence that comes from outside your own experience, such as focus groups, surveys and interviews with people who have no reason to be kind to you. Friends and former colleagues will usually say the idea is good because they like you and the question sounds rhetorical. The useful signal is finding people who are visibly frustrated with how they solve the problem today. How do you tell a real market from a polite one? Ask how people meet the need right now without your product, then ask how they feel about doing it that way. Someone grumbling about a spreadsheet every Sunday night is a market. Someone perfectly content with that spreadsheet is not. What happens when the research says no? You stop, and you stop having spent a fraction of what a build would have cost. One product aimed at African communities living abroad was shelved after focus groups showed people were already staying in touch in ways that suited them. That finding saved the entire budget rather than losing it. Can a project still fail even if the idea is sound? Yes, which is why feasibility also tests scope, budget and whether the people paying for it are ready to make decisions. A sports club app covering finances, games, schedules and players across multiple sports never reached the app store because the budget disappeared into feature after feature. Unchecked scope can kill a viable idea just as effectively as weak demand. ## Related Articles [![How Can I Use Government Grants to Fund My App?](https://weareaffective.com/hubfs/learning-centre-images/how-can-i-use-government-grants-to-fund-my-app.webp)](https://weareaffective.com/learning-centre/how-can-i-use-government-grants-to-fund-my-app) ### [How Can I Use Government Grants to Fund My App?](https://weareaffective.com/learning-centre/how-can-i-use-government-grants-to-fund-my-app) Government grants exist for exactly the kind of product you are building. That is a practical... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![What security testing should every app go through](https://weareaffective.com/hubfs/learning-centre-images/what-security-testing-should-every-app-go-through.webp)](https://weareaffective.com/learning-centre/what-security-testing-should-every-app-go-through) ### [What security testing should every app go through](https://weareaffective.com/learning-centre/what-security-testing-should-every-app-go-through) A product that reaches users with a security flaw baked in does not get a quiet second chance. The... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![Logistics App Success Stories Learning From the Companies That Got It Right](https://weareaffective.com/hubfs/learning-centre-images/logistics-app-success-stories-learning-from-the-companies-that-got-it-right.webp)](https://weareaffective.com/learning-centre/logistics-app-success-stories-learning-from-the-companies-that-got-it-right) ### [Logistics App Success Stories: Learning From the Companies That Got It Right](https://weareaffective.com/learning-centre/logistics-app-success-stories-learning-from-the-companies-that-got-it-right) The logistics app that works in the real world looks very different from the logistics app that... 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.