What makes a mobile app feasibility study successful

A feasibility study for a mobile app is the real work, or at least the part that determines whether everything after it is money well spent or money gone. We have seen both outcomes, and the difference between them almost always traces back to what happened, or did not happen, before a line of code was written.

A feasibility study asks whether the product should exist at all, and whether the conditions support building it now.

The word "feasibility" sounds procedural, like a compliance step. In practice, a well-run study is an act of honest questioning. It asks whether the product should exist at all, whether the people it is meant for actually want it, and whether the technical and commercial conditions support building it now. Those are uncomfortable questions for a founder who has been living with their idea for months. They are also the only questions worth asking at this stage.

What follows is what we have learned about making these studies produce decisions that hold, not just a report that sits in a shared drive and gets ignored when enthusiasm overtakes evidence.

What a feasibility study is actually trying to do

The purpose of a feasibility study is to reduce the cost of being wrong. That sounds obvious, but in practice it gets treated as an approval mechanism, a process that exists to confirm what people already believe. Run that way, it confirms nothing useful and generates false confidence, which is more dangerous than no study at all.

A study that is actually trying to do its job starts by mapping the assumptions underneath the brief. Every product pitch rests on a stack of beliefs: that people have this problem, that they have it frequently enough to download an app, that they would prefer a digital solution to whatever they do now, that the technical approach is achievable within the budget, and that the market is not already covered by something better. None of these are facts at the start. They are guesses, and the study's job is to find out which ones are solid and which are not.

We also ask something that sounds simple but regularly changes the direction of a project: how do people currently handle this without the app, and how do they feel about that? If the answer is "reasonably well and without much frustration, " the case for building a technical solution becomes much harder to make. The emotional texture of the current experience matters as much as its functional gaps.

Identifying which assumptions are most likely to be wrong

Not all assumptions carry the same risk. Some, if wrong, mean a minor adjustment to scope. Others, if wrong, mean the entire product has no reason to exist. A good feasibility study identifies which assumptions fall into which category, and tests the dangerous ones first.

We worked on a product aimed at expats living abroad across various countries. On paper the scope seemed clear, and the client had a confident view of what the market needed. The discovery phase told a different story. What the market actually needed was far from what the client had assumed, and uncovering that early saved significant time and money that would otherwise have gone into building something that was not fit for purpose. The study did not kill the project, it redirected it before the wrong version got built.

The assumptions most likely to be wrong are usually the ones the founder feels most certain about. Certainty is not the same as evidence, and the two are easy to confuse when you have been close to an idea for a long time. Simon warns against a specific trap here: it is very easy to think "I have this problem, therefore everyone has this problem, " and that is simply not the case. A focus group or a survey with people who are not already close to the product is the fastest way to find out whether a broader need genuinely exists.

Testing user demand before a line of code is written

There is a persistent gap between what people say they will do and what they actually do. When asked whether they would use an app, between 60% and 80% of respondents typically say yes, but actual usage, once the app exists, tends to land between 10% and 20%, according to AppTweak. This gap is a sign that the right kind of research goes beyond asking whether someone would use something and instead observes how they behave when faced with it.

Testing demand before build means putting something in front of real prospective users, whether that is a prototype, a concept board, or a structured interview, and watching what they actually do rather than what they say they would do. Do they understand what the product is for within the first 60 seconds? Can they complete the first action without help? Do they reach for the features the founder assumes are the draw, or do they ignore them?

We also look at five specific things before we would consider a product ready to launch: a validated user need that goes beyond the founder's own experience, an onboarding flow that real users have moved through without confusion, a value proposition visible within the first minute, a path to first value that has no friction points, and no moment where the user is overwhelmed before they understand why they are there.

Run your concept past five people who have no connection to the idea. Watch where they hesitate, not what they say when you ask them. Hesitation is data that conversation masks.

What happens when discovery is skipped on a single feature

Discovery is not just a whole-product question. It applies at the feature level too, and skipping it for even one component can undermine the rest of the product. We ran into this directly on a dating app project where the entire premise was built around verified profiles and the prevention of bots.

The client chose to skip discovery for the messaging component and focus the study purely on onboarding. The result was a generic messaging feature that had no relationship to the core product premise. It allowed automated and fake messages, which directly contradicted the verification work the onboarding had done. The two parts of the same product were pulling in opposite directions.

Skipping discovery for one component can undermine everything the rest of the product was built to do.

Fixing it required a full rewrite of the messaging section: approximately £15,000 in additional budget and two months of extra work. That figure is what happens when the assumption that a feature is "standard" goes untested. Messaging is messaging, until your product's core claim depends on it being something different, and nobody thought to check whether the build reflected that.

For every feature in your roadmap, ask whether it needs to behave differently because of what makes your product distinct. If the answer is yes, that feature needs its own discovery, not a borrowed template from a different product category.

When founder conviction overrides research findings

We have seen a pattern appear across two separate projects, a fitness and wellness app and a grassroots football product, that is worth naming directly. In both cases, the founder had strong personal conviction about what the product should be. In both cases, research, focus groups, and surveys produced data that pointed in a different direction. And in both cases, the founder chose to follow their conviction rather than the evidence.

The warning signs looked the same in both projects: a drive to perfect the product before launch rather than ship and learn, a pattern of rolling back decisions already signed off to request further changes, and a prolonged build phase that consumed budget without producing a live product. We flagged what was happening in both cases, but both projects exhausted their budgets in design and build without ever reaching a fully live version.

We describe this outcome as a vanity product, a product shaped by the founder's preferences rather than user evidence. The product becomes a mirror of what the founder wants to have built, not what users need to have available. A pre-launch founder in the football industry came to us with a colour-coded spreadsheet mapping out competitor products, aiming to merge multiple apps into one. When we started asking why a user would pick an all-in-one product over a specialist one, and whether consolidation would weaken each individual feature, the founder became deflated. That discomfort is understandable. Addressing it is the job.

Technical feasibility and the constraints nobody writes down

Technical feasibility is more than asking whether something can be built. It is asking whether it can be built at the right cost, within the right timeframe, for the right users on the right devices. These are different questions, and the gap between them has sunk more than one project.

We worked on a product aimed at African communities living abroad, designed to help people maintain connection with their home communities. Focus groups with the target market revealed insufficient desire for the product, which was the primary problem. But there was a second, layered issue: the capabilities of devices commonly used in African countries at the time were limited enough that delivering half of the intended experience on those devices would have been extremely challenging. The project was commercially unvalidated and technically constrained by the device landscape of one of its key user bases. Neither of those facts appeared in the original brief.

The constraints that surface late

Device fragmentation, operating system version spread, offline functionality requirements, and third-party API limitations are the constraints that most often get written around in early briefs rather than written down honestly. They appear later, during build, when changing course is expensive. A thorough feasibility study surfaces them deliberately, because a constraint named early is a decision. A constraint discovered mid-build is a crisis.

What the budget actually buys

Technical feasibility also means being direct about what the available budget realistically produces, and this is where a clear app planning and strategy process proves its worth. Iterating heavily before launch only makes sense if the budget can carry it. For most projects, launching a working product, observing what resonates, and then allocating further investment to the next iteration is a better use of money than pursuing a pre-launch ideal that the budget cannot reach. The product that ships is worth more than the perfect version that never does.

How to structure the debrief so decisions actually stick

A feasibility study produces findings. A debrief is where those findings become decisions. The two are not the same, and a poorly structured debrief is one of the most common ways good research fails to change anything.

The sequence we use moves through four stages. First, we establish what was tested and what the research was trying to find out, because context matters when a room full of people is about to argue about findings. Second, we review the profiles of the people whose feedback is on the table. Not every user is equally relevant to every feature, and weighting feedback without knowing who gave it leads to poor decisions. Third, we map the business value and likely user uptake of each feature under discussion. Fourth, we apply an effort versus impact assessment to determine what goes into the next build, what gets deferred, and what gets dropped entirely.

Before the debrief, share the user profiles of research participants with everyone in the room. It stops the conversation becoming "I think users want X" and grounds it in "the users we tested, who look like this, did or did not respond to X."

That last category, what gets dropped, is where the debrief earns its value. A debrief that only produces a prioritised list of things to build has not done its job. The decision not to build something, made with evidence and recorded, is what prevents the same feature returning in six months with a new champion and no memory of why it was set aside.

What a feasibility study cannot tell you

A feasibility study can tell you whether a need exists, whether prospective users understand the product, whether the technical approach is sound, and whether the assumptions underneath the brief hold up. It cannot tell you whether the product will succeed once it is in the market. Those are different questions, and conflating them produces overconfidence in the output.

Research done before launch is, by definition, research done in an artificial context. Users are reacting to a prototype or a concept, not to a live product embedded in their actual lives. The behavioural gap between stated intent and real use is well-documented: far more people say they would use something than actually do when it exists and competes for their attention against everything else on their phone. Feasibility research narrows the gap. It does not close it.

There are things only the market can answer: whether the timing is right, whether a competing product will launch in the same window, whether the acquisition costs are sustainable at scale. A feasibility study that claims to answer those questions is overstating what research at this stage can produce.

The honest framing is this: a feasibility study tells you whether it is reasonable to proceed, and on what terms. It is not a guarantee. The meditation app teardown we ran illustrated this clearly, the visual design was doing good work, slowing users down behaviourally with soft gradients and breathing animations, but the onboarding asked users to choose a goal before they had experienced anything. A decision point that early adds friction, and friction at the start of a meditation app increases the anxiety the product is meant to relieve. The study could identify that. Only a live product would show whether fixing it meaningfully changed retention.

Conclusion

A feasibility study succeeds when it changes what gets built. Not when it validates what was already planned, not when it generates a report that sits behind a promising executive summary, but when it produces decisions, about what to build, what to defer, what to drop, and what to find out first before committing any further budget.

The studies that fail tend to share a common shape: they are run too quickly, they test assumptions the team already believes in, they skip discovery for features that seem standard, and their findings get overridden when a founder's conviction is strong enough. We have seen that pattern end two projects without a live product between them.

The studies that work start by naming what is not yet known, prioritise testing the assumptions that carry the most risk, bring real prospective users into the process before a single screen is designed, and structure the debrief so that the decision not to build something is as clearly recorded as the decision to build it.

Getting this right at the start does not mean the product will succeed. It means the product that gets built will have been worth building, and that the money spent on it went to the right version of the idea. If you are at the start of that process and want to work through it properly, let's talk about your app feasibility study.

Frequently Asked Questions