Which Criteria Determine if Your App Idea Is Technically and Financially Feasible

We worked on a product aimed at African communities living abroad, built to help people keep a connection with their home communities. The technology was straightforward and the build was well within reach. We ran focus groups with the target market and what came back was that there just wasn't a desire for that kind of product. So when a founder asks us "is my app idea feasible", the first thing we do is ask what they mean by feasible, because that single word is hiding at least five separate questions.

Feasibility is a set of smaller judgements, and any one of them can stop the whole thing.

Most of the time the question arrives attached to real money. Someone has a budget, a rough spec, a date in their head and a board or a partner waiting for an answer. A yes that only covers the engineering is worth very little, because the engineering is rarely the thing that sinks a project.

What follows is how we actually test an idea before anyone writes a line of code. Demand, money, devices, dependencies, rules, scope and the people making the decisions. We've drawn on projects where each of those went well and projects where they didn't, including a few that cost our clients real money to put right.

Why Feasibility Is a Layered Judgement, Not a Single Yes or No

An app idea can pass the technical test comfortably and still fail. The African diaspora product proved that for us. It was technically viable and fairly straightforward, and the research told us the market wasn't there. Both findings were true at the same time, and only one of them mattered for the decision.

So we treat feasibility as layers. Each layer asks a different question and each has its own way of going wrong.

A proper app feasibility study works through all five. Pass four and fail one and the project still stalls, usually late, usually after the budget has gone into design and build. The point of doing this early is that four of those five layers are cheap to test with conversations, research and a spreadsheet.

Evidence of Demand: Does Anyone Outside the Room Want This?

The hardest layer to test honestly is the first one, because the person asking usually believes in the idea already. On the African diaspora product we ran lots of focus groups with the target market, and the research was clear enough that the commercial case fell apart. That finding saved a client a great deal of money, and it still took weeks of talking before it was accepted.

Testing "is my app idea feasible" with real users

We've watched the opposite happen twice. On a fitness and wellness app and on a grassroots football product, both founders were very sure of what they wanted, mostly because they were solving a problem they personally had. Research came back, focus groups came back, surveys came back, and the data got set aside. What gets built then is a vanity product, shaped by the founder's taste rather than by evidence. Both projects used all their budget in design and build and never reached a full live version.

Write down, before research starts, what finding will make you stop. If there's no result that changes your mind, you're buying reassurance rather than evidence.

Demand evidence doesn't have to be expensive. Focus groups, a landing page with real sign-ups, interviews with twenty people who match the target market. The test is whether anyone outside the founding room gets excited without being led.

The Commercial Model: What People Will Actually Pay

On the music app project, the client came from the music world and knew exactly what it had cost them to produce the recordings. They wanted to recoup that cost within weeks, and that's just not how consumer app economics work. The production spend became the anchor for the price, which meant a lower price point and a longer volume play were never properly on the table.

What it cost to make the thing has no bearing at all on what a customer is willing to pay for it.

Pricing feasibility is arithmetic. Price, conversion rate, how many people you can realistically reach, how long they stay, what it costs to acquire each one. If those five numbers don't produce a business when you're generous with them, they certainly won't when you're honest.

Clarity matters as much as the number. On a marketplace checkout project, we saw confusion around platform fees cause real hesitation and drop-off. Whether the fee sat on top of the price or was already included was the issue rather than the size of the fee. Even small amounts dented trust at the point of payment when people couldn't tell what they were being charged.

Budget Versus Ambition: Does the Money Match the Product You Are Describing?

We worked on a football-focused social media app where the client asked for a streamlined MVP-style first release and then described a premium experience in every other conversation. A smaller budget brings less flexibility and a sharper focus on getting something launchable into the market. This client wanted the low budget without the limitations that come with it.

We had several conversations trying to line up the expectation with the financial reality. The project did reach a finished product, with compromises on features, because budget went into areas our team ranked as lower priority. Nobody was being unreasonable. The gap sat between what the money bought and what the picture in their head looked like, and that gap never fully closed.

Budget overrun isn't rare either. McKinsey found that 45% of IT projects exceed their budget, and large projects run 45% over while delivering 56% less value than predicted, according to McKinsey.

Price the product twice. Once as the full version in your head, once as the smallest thing worth launching. If the two numbers are far apart, decide which one your budget is actually buying before design starts.

A budget is a statement of what you're prepared to cut. Teams that accept that early get a working product. Teams that don't spend the same money and get a half-built one.

Devices, Networks and Infrastructure Your Real Users Have

The second reason the African diaspora product didn't go ahead was hardware. The devices commonly used across African countries at the time had very limited capability, and delivering half of the intended experience on those handsets was going to be incredibly challenging. The experience we'd designed assumed phones that a big part of the audience simply didn't own.

That question comes up more often than founders expect. Video, live features, offline sync, large downloads, heavy animation and background location all make assumptions about the phone, the network and the data plan. Testing on a current flagship over office wifi tells you almost nothing about a three-year-old mid-range handset on patchy mobile data.

The first few seconds decide a lot

We talk about immediate abandonment, which happens in the first three or four seconds. Slow loading, sluggish interactions, a crash or a freeze, and the person is gone before they've seen anything you built. Storage and battery drain do the same job more slowly, over the first few weeks.

So part of any honest technical read is a profile of the real device landscape. What phones does this audience hold, what connection do they have, how much space are they willing to give you. Those answers change what's buildable far more than the cleverness of the feature list does.

Dependencies You Do Not Control: Platforms, APIs and Partners

We worked on a currency exchange product that let travellers pass leftover foreign currency to each other at an agreed rate, skipping bank and bureau fees. Partway through the project we discovered that both the legal position and Apple's App Store requirements ruled out direct peer-to-peer transfers of that kind. The core idea of the product sat inside something we had no power over.

The fix was a full pivot. The product became location-based and in person, where two people meet up and physically exchange the currency rather than sending money remotely. It worked, and it was a very different product from the one that had been scoped and sold internally.

List every outside party your idea depends on before you start, and for each one write what happens to the product if they say no. If any answer is "there's no product", that dependency gets checked first.

Every app leans on things somebody else controls. Payment providers, map data, identity checks, a partner's stock feed, the two app stores, a third-party booking system. Each one has terms, rate limits, fees and the right to change any of it. Reading those terms during feasibility is dull work and far cheaper than discovering the answer in month five.

Regulation, Compliance and App Store Rules

The same currency exchange product taught us a second lesson. We built the core transfer mechanism well and we didn't factor in anti-money laundering. Apple raised a specific concern that the product could be used for money laundering, because transfers between users had no ceiling on them.

We went back and retrofitted compliance in layers. More stringent know your customer checks at sign-up, stronger security around each transfer, and hard limits on how many transfers any two people could make between them. All of that was achievable. Doing it after the build cost far more than designing it in at the start.

Compliance designed in at the start is a feature. Compliance retrofitted after launch is a rebuild with a deadline.

Money, health data, children, user-generated content and anything touching identity all bring rules with them. GoodFirms notes that highly regulated sectors can see development budgets rise by 30-50% because of compliance, security and data protection work, according to GoodFirms.

App store review is its own layer on top of the law. Something can be perfectly legal in your market and still be refused by Apple or Google on policy grounds, and neither of them is obliged to explain at length or move quickly.

Can It Launch in Stages? Scope and Release Feasibility

Simon worked on a well-funded sports club app built to handle finances, games, schedules and players across a range of sports. We advised launching with a single sport, on a single platform, as an MVP. The client pushed back through the entire process. They wanted to launch everything, they didn't want to go live until all of it was ready, and they wouldn't accept a first release that covered one sport or one platform.

That stance set the conditions for scope creep with no natural stopping point. Working with the development process and listening to professional advice matters more than almost anything else at this stage, because a project that can't be cut into releases has no way of proving anything until the money has gone.

When we test whether an idea can ship in stages, we're looking for a sequence like this.

1. One audience, one platform, one core job the product does.
2. A release that's genuinely usable on its own, even if it's narrow.
3. A second release that adds the next most wanted thing, based on what real users did.
4. A point where the product earns revenue before the full feature set exists.

If an idea can't be divided that way, that's a feasibility finding in itself. Geneca's survey found up to 77% of software project respondents don't know how to tell when their project is done, reported by Geneca.

Are the Decision-Makers Ready? The Human Side of Feasibility

On a fitness and wellness product with two co-founders who were new to app development, we hit the same cycle over and over. We'd get sign-off on a design, start building it, and then the approval came back the other way, with one of them saying they hadn't understood that this was what we'd actually build.

There was no real consensus between the two of them. Approval was being given to be polite rather than as a decision anybody intended to stand behind. We kept warning them that budget was going on design iterations that wouldn't have a material impact on the product, and that fell on deaf ears. The work finished in the design and research stage because the money ran out there.

Questions worth asking before the build starts

Readiness is a feasibility layer like any other. We look at who signs off, whether that person has authority to say no and make it stick, how long decisions take, and whether the founding team agrees on what the product is when they're in separate rooms.

Two founders with different pictures of the product will spend their budget arguing through the design phase. That's a solvable problem in week one and an expensive one in month six.

Early Warning Signs That a Project Is Heading for Trouble

Across the fitness and wellness app and the grassroots football product, the same signals showed up early. We flagged the trajectory on both, and both still ended with the budget gone before a full live product existed.

• A drive to perfect everything before anyone outside the team has used it.
• Sign-offs that get rolled back with fresh change requests attached.
• Decisions that take weeks and then get reopened.
• Research findings that get explained away rather than acted on.
• A budget that's being spent on refinement rather than on getting something shippable.

Skipping research is its own warning sign. On a dating app project built around verified profiles and keeping bots out, the client wanted to skip discovery on the messaging side and put everything into onboarding. What we built was a generic messaging feature that allowed automated and fake messages, which contradicted the whole premise of the product. Rewriting that section cost roughly £15,000 of extra budget and about two months of extra work.

If a stakeholder asks to skip discovery on one part of the product, check whether that part touches the core promise. If it does, the saving is a loan at a very high rate.

Devtimate puts projects that skip the discovery phase at 3-5 times more likely to fail or exceed budget, reported by Devtimate.

What a Feasibility Study Involves and What You Get Back

WAA worked with a property developer building a concierge app for high-rise properties. They arrived with a suggested budget and a formed idea of what they wanted, really looking for a quick validation rather than a full scoping exercise. We talked them into a proper discovery phase with focus groups and user workshops first.

What we found was that the product needed to be a lot simpler than they'd pictured. A good number of the features they'd planned didn't go in. Instead we focused on creating a human connection with the product rather than replacing systems the building already had working perfectly well.

Discovery made that product smaller, better and cheaper, which is three outcomes nobody expects from the same piece of work.

An app feasibility study with us runs through research with the target market, a technical read on devices and dependencies, a commercial model with real numbers in it, and a regulatory check covering both law and app store policy. Everything is delivered under the WAA name.

What you get back is a clear recommendation on whether the idea is technically and financially feasible, a staged release plan if it is, a list of the things that'll cost more than you think, and an honest note on anything we can't make work within the budget you've described.

Conclusion

The question "is my app idea feasible" has more than one answer, and the useful ones are rarely about engineering. The African diaspora product was buildable and nobody wanted it. The currency exchange product was wanted and the rules got in the way. The sports club app had funding and no willingness to launch in stages. Each failed on a different layer, and each failure was visible before the money went.

Testing those layers is quick work compared with building the wrong thing. A few weeks of focus groups, a device profile, a pricing model with pessimistic numbers in it, a read of the app store policies and a frank conversation about who signs off. Most ideas survive that process in a changed shape, which is the point. The concierge app came out smaller and better than the version that walked in the door.

If you're sitting on an idea with a budget attached and you want a straight answer on whether it holds up technically and financially, we're happy to look at it with you. Let's talk about your app idea and work out which layer needs testing first.

Frequently Asked Questions