How Do You Build a Comprehensive App Feasibility Framework?

Most app projects that fail do not fail at launch. They fail much earlier, in the decisions made before a single line of code is written, and the people involved often do not realise it until the budget is gone. We have seen this pattern often enough that it shaped how we approach every new brief: not with enthusiasm for the idea, but with a structured set of questions designed to find the breaks before they become expensive.

A feasibility framework finds the breaks in the plan before they become expensive to fix.

A feasibility framework tests whether a product can actually be built, adopted, and sustained, and whether the version the client has in mind is the right version to build at all. The difference matters because clients rarely arrive with a bad idea. They arrive with an incomplete one, and the framework's job is to make that visible before money fills the gaps.

What follows is how we build and run that framework, drawn from the projects where it worked and, just as usefully, the ones where corners were cut and the consequences were real.

What a Feasibility Framework Actually Needs to Test

The word "feasibility" tends to make people think of budgets and timelines. Those matter, but they are outputs of a deeper set of questions. A framework that only asks "can we afford this?" will produce a confident yes right up until the moment the project collapses because nobody validated whether anyone actually wanted it.

A complete feasibility framework tests across six distinct dimensions: technical complexity, scope control, market readiness, user behaviour, internal consistency, and commercial viability. Miss any one of them and you have a partial picture, which is often more dangerous than no picture at all, because it produces false confidence.

The order matters too. Testing commercial viability before you understand technical complexity means you are pricing something you have not yet defined. Testing market readiness before you understand user behaviour means you are measuring demand for a product that may not match how real people actually operate. The framework works as a sequence, not a checklist you can complete in any order.

Run the six dimensions in order. Each one narrows the definition of the product, so later tests become more accurate the more precisely the earlier ones have been answered.

Technical Complexity: Where Projects Quietly Become Undeliverable

The API question nobody asks early enough

Technical complexity is the dimension most founders underestimate, and they underestimate it because the early conversations are about features, not infrastructure. A feature sounds simple to describe. Building it often is not. The difference between integrating an existing API and developing one from scratch, for example, can cause a project budget to be underestimated by a factor of three to five times, according to Planeks. That is the kind of gap that kills a project mid-build.

The grassroots football club app we worked on is the clearest example we have of this pattern. The client wanted to replicate several different apps into one product. We advised launching a limited feature set first, testing the market, and growing from there. The client would not take that advice. The scope kept expanding, the technical complexity compounded, the budget kept rising, and the product never launched. The warning signs were there from the earliest conversations, but the client treated technical concerns as pessimism rather than professional judgement.

Simon draws a clear lesson from that project: working with the development process and listening to professional advice is what keeps a product deliverable. Resisting iterative methodologies and MVP thinking in favour of launching everything at once puts the whole project at risk of never launching at all.

Scope Creep as a Feasibility Risk

When the product keeps growing

Scope creep is usually framed as a project management problem, something to be handled with change control processes and stakeholder sign-off. We think of it differently. Uncontrolled scope is a feasibility risk, because a product that doubles in scope mid-build is effectively a different product from the one that was assessed as buildable in the first place.

The football club app illustrates this precisely. The product the client described at the start was not the product they were chasing by the end. Each addition felt reasonable in isolation, but collectively they created something nobody had ever formally assessed for feasibility. The budget that was agreed for one product was being spent on a different, much larger one.

A product that doubles in scope mid-build is a different product from the one assessed as feasible at the start.

The Standish Group's CHAOS Report data suggests 45% of features in software projects are never used. If almost half of what gets built goes unused, the feasibility question is whether everything on the list should be there at all. A framework that does not actively prune scope is documenting ambition.

At each scope review, ask whether a newly added feature was in the original feasibility assessment. If it was not, it needs its own mini-assessment before work begins, not after.

Market Readiness: Beyond Competitor Spreadsheets

A pre-launch founder in the football industry came to us with a colour-coded spreadsheet mapping out competitor products, with the aim of merging multiple products into one. The founder was visibly excited. When we began asking questions about prospective users, specifically why someone would choose an all-in-one product over specialised apps and whether consolidation would dumb down individual features, the energy in the room shifted. The founder became deflated. But those are exactly the right questions to ask before a product is built, not after it has shipped.

Founders gravitate towards competitive feature mapping because a spreadsheet provides immediate, unchallenged validation of their existing opinions. User research carries a different kind of risk: it might reveal that the idea needs significant changes, or that nobody wants the product in the form currently imagined. A feasibility framework has to confront that risk deliberately.

Our approach to market readiness starts by asking what need the product will fill and how people are currently meeting that need without it. Crucially, we also ask how people feel about their current process. If users are broadly content with a manual approach, there is no compelling reason to build a technical solution. The focus is on identifying where the current process is genuinely failing people, emotionally as well as functionally, because that is where real demand lives.

User Behaviour: Why Feature Parity Is Not Enough

There is substantial research showing that feature parity alone is not sufficient for a product to succeed. Having the same or even superior features to competitors does not guarantee adoption. What matters is understanding users' emotions, their specific use cases, and the context in which they operate. A feature that works well in one scenario cannot simply be transplanted into a different context and expected to perform the same way.

The numbers on stated versus actual behaviour make this concrete. When users are asked whether they would use an app, 60 to 80% typically respond positively, according to AppTweak, but actual usage is often only 10 to 20%. That gap is the distance between what people say they want and what they actually do when a product is in front of them. A feasibility framework that relies on stated intent without testing actual behaviour will consistently overestimate demand.

This is why we put real users in front of prototype flows as part of feasibility, not just market sizing exercises. The question is not whether users say they would use this. The question is whether they can complete the first value-generating action without friction, whether the product's core proposition is clear within the first 60 seconds, and whether there are points of friction or psychological pressure in the journey that would cause them to leave before they reach value.

Test actual behaviour, not stated intent. Put a prototype in front of real users early enough that what you learn can still change what you build.

Internal Consistency: When One Part of the Product Contradicts Another

The cost of a single skipped discovery

Internal consistency is the dimension that gets skipped most often, because it requires holding the entire product in mind at once. Teams naturally focus on the part they are currently building. The problem is that parts of a product can contradict each other in ways that only become visible when they are placed alongside each other, and by then the work is already done.

We ran into this directly on a dating app project. The product's core premise was verified profiles and the prevention of bots, which meant the onboarding process was built with significant rigour around identity verification. The client chose to skip discovery for the messaging component and focus solely on onboarding. That decision resulted in a generic messaging feature being built that allowed automated and fake messages, directly contradicting everything the verified onboarding was designed to prevent.

The mismatch between the rigorously verified onboarding and the permissive messaging system meant the entire messaging section had to be rewritten. That cost approximately £15,000 in additional budget and two months of extra work. The irony is that the client skipped discovery on messaging to save time and money, and the consequence was the opposite of both. A feasibility framework that checks internal consistency before build prevents exactly this kind of expensive contradiction.

The removal test as an audit tool

One tool we use to check internal consistency is what we call the removal test. Ask what would happen to engagement metrics if a specific feature were disabled for a particular group of users. If the team's instinctive answer is "we'd never do that, " that reaction is itself diagnostic. It signals the feature is retained primarily to drive platform metrics rather than to serve users, and that the team implicitly knows this. A feature that cannot withstand the removal test is a feature that needs to be re-examined before it ships.

Commercial Viability: Budget, Timeline, and the Real Cost of Getting It Wrong

Commercial viability is where the feasibility framework becomes a conversation about numbers, and those numbers need to be grounded in what the discovery process has actually found, not in what the client hoped to spend. A ballpark estimate carries roughly ±50% accuracy, whereas an estimate built on a proper discovery phase narrows to ±10 to 20% accuracy, according to Devtimate. That difference is the financial case for doing discovery properly.

We worked with a property developer building a concierge app for high-rise properties who came to us with a suggested budget and a pre-formed idea of what they wanted. They were looking for validation rather than a full scoping exercise. We convinced them to undertake a proper discovery phase, including focus groups and user workshops. What we found was that the product needed to be far simpler than they had envisaged. Many planned features were dropped entirely, and the focus shifted to creating a human connection with the product rather than replacing existing building systems. The result was a better product built at a lower cost than originally budgeted.

The discovery process did not just save money on features that would not have worked. It redirected the budget towards the thing that would actually make the product succeed. That is what commercial viability assessment is for. The goal is to confirm the product can be built within a budget that makes commercial sense, and that the version being built is the one worth spending that budget on.

Running the Discovery Phase That Makes the Framework Work

Discovery is the engine of the feasibility framework. Without it, the framework is a set of questions with no answers. With it, the questions get answered in the right order, by the right people, before any significant budget is committed.

Our discovery process follows a clear sequence. First, we establish what is being tested and what the goals of the research are, whether that is feature exploration, concept validation, or understanding the current user experience of a problem. Second, we review the profiles of research participants so we can weight their feedback appropriately, since not every user is equally relevant to every feature. Third, we map the business value and potential user uptake of each feature under discussion. Fourth, we apply an effort versus impact matrix to determine what should be prioritised, deferred, or dropped entirely.

When stakeholders challenge findings on the grounds of sample size, we accept that any number of real voices adds value over none, and if findings point to significant changes, we table those points and assess their potential business impact. If sample size concerns persist, we move from exploratory qualitative research into large-scale quantitative validation through predefined surveys, which can reach far more respondents than one-to-one or group sessions alone.

1. Establish what is being tested and the research goals
2. Review participant profiles to weight feedback accurately
3. Map business value and potential user uptake per feature
4. Apply an effort versus impact matrix to set priorities
5. Escalate to quantitative validation if sample size is challenged

How to Reach a Go or Pause Decision

The purpose of the framework is to reach a decision. Not a list of caveats, not a phased approach that defers the hard question, but a clear position: this product is ready to build in this form, or it is not yet ready and here is what needs to change before it is.

A go decision requires satisfactory answers across all six dimensions. A weakness in one does not automatically produce a pause, but it does require a clear plan for how that weakness will be addressed and when. A product with an unresolved technical complexity question is not ready to build. A product with an unvalidated user need is not ready to build. The framework's job is to make that visible before the budget commits rather than after it is spent.

A pause decision should come with specifics. What needs to be resolved, who is responsible for resolving it, and what the decision point looks like once that work is done. A pause without a clear path back to go is effectively a stop, and the client deserves to know that clearly rather than through gradual budget attrition.

Frame the go or pause decision as a set of conditions, not a binary. What is confirmed, what is still open, and what would need to be true for the open items to close.

Conclusion

A feasibility framework is the thing that makes execution possible. The projects we have seen fail, from the grassroots football app that never launched to the dating app messaging system that had to be rebuilt at a cost of £15,000 and two months, share a common pattern: a dimension of feasibility was not tested before it became expensive to fix.

The property developer who came to us wanting validation and left with a simpler, better product at lower cost is the other side of that pattern. Discovery did not slow that project down. It redirected it towards something that could actually succeed, which is what a feasibility framework is supposed to do.

The framework works because it forces completeness. Across all six dimensions in sequence, with real users, real data, and real decisions at each stage. A product that passes all six is not guaranteed to succeed, but a product that skips any of them is already carrying a risk it has not yet named.

If you are building an app and want to know whether your current plan would survive a proper feasibility assessment, let's talk about your product.

Frequently Asked Questions