How Can I Find Out if My App Idea Is Any Good?

A grassroots football product we worked on is still announcing "coming soon". That was more than a year ago, from a standing start, with the design and build budget already spent. The founders were certain about what the product should do. The research kept pointing somewhere else, the feature list kept growing, and in the end development had to stop and we stopped working with them.

An app idea is a guess about someone else's life, and guesses can be checked before they're built.

So if you're sitting on something and quietly wondering "is my app idea any good", you're asking the question that saves the most money, and you're asking it at the only point where the answer is cheap. Ask it after the build and the answer arrives as a launch nobody turns up to.

What follows is how we go about it when a founder comes to us with an idea and a budget. Some of it is research, some of it is honesty about what the research says, and a fair bit of it is noticing when an idea is really two or three ideas pulling in different directions. None of it needs a line of code.

What 'Good' Actually Means for an App Idea

Good has very little to do with how the idea sounds out loud. An app idea is good when a problem already exists in people's lives, when those people are doing something clumsy about it right now, and when they'd happily swap the clumsy thing for yours.

Simon reduces it to one question for founders. "Are you solving a real problem that people will pay for? Or are you yourself in love with the solution?" That question filters quite hard, and it's meant to. It separates products the market will take from what we call vanity products, built mainly to satisfy the founder's own picture of things.

Is my app idea any good?

Nobody can answer that from the idea alone, including us. What you can do is break it into smaller questions that have checkable answers. Who has this problem, how often does it bite, what are they doing instead, and what would they give up to stop doing it?

And the problem worth finding is an emotional one as much as a practical one. As Simon puts it, "what is the actual problem that we're solving from an emotional perspective, not just a functional one." People don't book a class because booking is hard. They book because they don't want to turn up somewhere and feel out of place.

Start With the Problem, Not the App

Clients usually arrive with a product in mind. We take it back a step and ask what problem they believe that product solves, then work forward from there. Simon's version of this is blunt. "A lot of clients come to us with a product they want to build when in reality they're solving a problem."

We worked on a concierge app for a premium property development. The brief, more or less, was a digital version of everything the concierge does. We ran focus groups with residents, and the problem underneath turned out to be communication. People didn't know their neighbours and weren't talking to each other.

So we changed the product strategy. Rather than digitising the whole concierge role, we automated the mundane, routine requests so the concierge and the residents had time and energy left for actual conversation. We added personalisation so residents could see who lived around them, what they were into, and get to know the concierge as a person. Taking friction out of the dull stuff made room for the social stuff.

Built exactly as briefed, that product would have worked perfectly well as software and missed the point entirely.

Proving the Problem Exists Beyond You

Nearly every app idea starts with a founder's own frustration, which is a fine place to start and a terrible place to stop. Simon's warning is the one we repeat most often. "It's very easy to think okay I have this problem therefore everyone has this problem and that's just not the case."

We worked on a product aimed at expats living in various countries abroad. On paper the scope looked straightforward and the client was clear about what the market wanted. After the discovery phase, the kind of product the market actually needed turned out to be very far from what the client had assumed, and knowing that before the build saved them a lot of time and money.

Your own frustration is a reason to go looking, never proof that anyone else cares.

This is the failure that kills more products than anything else. Post-mortem research from CB Insights puts "no market need" behind around 35% of startup failures, which is to say the founders assumed a demand that was never there.

Proving the need means talking to people who aren't you and aren't your friends. Focus groups, surveys, structured conversations with strangers who match the audience. We'd rather build a product people are going to use than one the founder thinks people are going to use.

How to Talk to People Without Leading Them

The quickest way to ruin research is to describe your app and ask if people like it. They'll say yes. They're being kind, they can't picture the thing properly, and agreeing ends the conversation faster than disagreeing does.

Stated intent is a weak signal at the best of times. AppTweak describes the gap plainly, with 60 to 80% of people saying they'd use an app against actual usage nearer 10 to 20%. So ask about the past instead of the future, because the past has already happened and can't be flattered.

• When did you last run into this problem, and what did you do about it?
• What did that cost you, in money, time or hassle?
• What have you already tried, and why did you stop using it?
• Who else was involved when it happened?

Record the words people use for their own problem and keep them. Those words belong in your onboarding copy later, because they're already the language your user thinks in.

Silence is your friend in these conversations. When somebody trails off, wait. The sentence after the pause is usually the honest one, and it's often the part they assumed you weren't interested in.

Reading the Evidence Honestly

Research only helps if you're willing to be told something inconvenient. The usual failure is reading the parts that agree with the plan and quietly discounting the rest as people not getting it yet.

We did a teardown of a meditation app that shows how this plays out in design. The visual work was doing its job well, with soft gradients and a breathing animation that slowed people down behaviourally before anything else happened. Then the app asked users to pick a goal, sleep or stress or focus, before they'd done a single thing in the product.

Choosing a goal in that state of mind adds a decision, and a decision is friction, which raises anxiety rather than relieving it. The app had promised calm in under a minute and then handed the user a small piece of homework. As Simon said about it, "nobody really opens a meditation app the first time because they're already calm and curious. They open it because they really need to destress."

We flagged it as a classic case of designing for the ideal user rather than the actual one arriving at your product. Honest reading means letting your evidence describe the person who turns up, including the anxious, distracted, half-committed version of them.

Warning Signs You're Building a Vanity Product

We've seen the same pattern run its course on two projects, a fitness and wellness app and the grassroots football product. In both, the founders held strong personal conviction about the vision, most likely because it was a problem they had themselves, and in both they set aside what came out of research studies, focus groups and surveys.

Simon's description of where that leads is that "the product becomes a vanity product". We flagged the trajectory early on both. Both ended up spending their entire budget on design and build without ever reaching a full live version.

The early signs are behavioural rather than technical, and they look like this.

• A drive to perfect everything before anyone outside the team sees it.
• Sign-offs that get rolled back so another round of changes can be requested.
• Decisions that take weeks and then get reopened.
• Research findings explained away as the wrong participants or the wrong questions.
• A feature list that only ever grows.

None of these feels like failure while it's happening. Each one feels like care. The difference is whether the care is aimed at the user or at the founder's own picture of the product.

When Two Good Ideas Are Fighting Each Other

Plenty of ideas aren't bad, they're just three ideas wearing one coat. That was the real story on the grassroots football app. The client compared each feature against a best-in-class competitor that did only that one thing, then asked us to make the booking process more intuitive.

We pushed back and then did what was asked. The changes made little to no difference, because the booking flow wasn't the problem.

There was a reason those features already lived in several separate apps, and we were cramming them into one.

Simon's summary of it holds up. "What the core problem was was that the client was just trying to do too much in one product." Despite real effort to make something cohesive and emotionally grounded, what came out was overly complex and too verbose, and it didn't serve the audience or the core purpose.

So when an idea feels slippery to explain, check whether it's actually two products. Write down who each part is for and what job it does. If the answers differ, pick the one with the sharper problem and build that. The other idea doesn't die, it waits.

The Feature Trap: Why More Rarely Means Better

Founders add features for comfort. Each one is a small insurance policy against the fear that the simple version won't be enough. The trouble is that every feature you add has to be designed, built, explained, maintained and then explained again to every new user who arrives.

Most of them never get used. Futuristic Bug reports that close to 60% of app features are rarely or never touched, which means a large part of the money goes into things nobody opens.

The cost that hurts most is attention. If your value proposition has to be visible within the first sixty seconds, every extra option in that window is competing with it. The football product got so complex that development had to stop. More than a year on from scratch, there's still nothing marketable out there, only shifting dates of coming soon.

Write the single sentence a user would say to a friend about what your app does for them. Any feature that doesn't help that sentence land goes on the later list.

Cutting features before launch is far cheaper than cutting them after, when people have learned where things are.

Testing Demand Before You Build Anything

You can learn a surprising amount about demand without a build. Business of Apps reports that 42 per cent of apps fail because they launched with no prior market research, and most of that research is work you can do in a few weeks.

Different tests answer different questions, and mixing them up is how founders end up confident about the wrong thing.

Delivering the outcome by hand is the one founders skip and the one we'd keep. If you can't make ten people happy with a spreadsheet, some messages and your own time, software won't rescue it. It'll just make the same mistake faster and in more places at once.

What Competitors and the Market Can Tell You

Looking at competitors tends to produce feature envy, which is how the football client ended up benchmarking every screen against a different single-purpose app. A more useful habit is to read other products the way we read that meditation app, by asking what emotional problem the design assumes the user has.

Their reviews do a lot of this work for you. One-star reviews describe moments of frustration in the user's own words, and three-star reviews are usually the most honest, because the person liked something and still couldn't stay. Look for the complaint that repeats across several different apps in the category, because that's a problem the whole market has decided to live with.

Sort a competitor's reviews by most recent rather than most helpful. Recent reviews tell you about the product as it is now, including whatever they changed last month.

An empty category is rarely a gift. A crowded one with grumpy users is usually a better sign, because it proves people want the outcome and haven't found a version they can stick with. What you're hunting for is the emotional gap that none of them have closed, not a feature none of them have shipped.

Deciding: Go, Pivot or Stop

At some point the evidence is in and a decision is owed. Founders often stretch this part out, because deciding means one of the possibilities has to be let go.

Go looks like consistent stories from people who aren't you, a problem that bites often enough to be worth solving, and a simple version you can describe in one sentence. Pivot is what happened on the expat product. The need was real, the shape of it was different from what the client assumed, and the discovery work moved them before the money went into the wrong build.

Stopping early is the cheapest decision available, which is why it almost never gets made.

Stop is the one worth being honest about. On both the vanity product projects, stopping in time would have left budget for a different attempt. Instead the money went into design and build for products that never went fully live.

If your research keeps telling you something you don't want to hear, that's data, and ignoring it doesn't make it less true. Give yourself permission to put an idea down. The founders who do it keep enough resource to try again with a better one.

Signals Your Idea Is Ready to Build

When a client asks us what we'd want to see before a build starts, the list is short and it hasn't changed much. These are the checks, roughly in the order you'd work through them.

1. A user need proved beyond the founder's own experience, through focus groups or surveys with real people in the audience.
2. An onboarding flow tested with those people, so you know what they understand and where they stall.
3. A core proposition clear enough to land within the first sixty seconds in the product.
4. A first useful moment the user can reach without friction, with nothing clever in the way.
5. Nothing that overwhelms people too early, which usually means fewer choices on the opening screens than feels comfortable.

After those, the secondary checks are worth a pass too. App store copy and screenshots, how the product is framed before anyone downloads it, and any safety features the audience needs.

Simon's own phrasing on the first set is worth keeping. "Those are the absolute must haves for me." If an idea clears all five, the question of whether it's viable has mostly answered itself, and the remaining risk sits in execution rather than in the premise.

Conclusion

The honest answer to "is my app idea any good" is that the idea isn't the unit worth judging. The problem underneath it is. Find out whether that problem exists for people who aren't you, how often it bites them, and what they're doing about it now, and you'll know more than any amount of refining the concept could tell you.

Every project we've described here turned on that one thing. The concierge app got better when we found the real problem was residents not talking to each other. The expat product changed direction because discovery showed the market wanted something else. The football product and the wellness app spent their budgets defending a picture of the product that the research kept disagreeing with.

None of this requires a huge spend up front. It requires a few weeks, some honest conversations and a willingness to be told no while being told no is still cheap.

If you've got an idea and you'd rather find out now than after the build, we're happy to look at it with you. Let's talk about whether your app idea holds up.

Frequently Asked Questions