How to Find and Validate Your Next App Idea

The most difficult part of making an app isn't the code or the infrastructure, not even the marketing. It's making an app people actually want or need. What might be useful for you doesn't necessarily mean it will be useful for the market.

While we're waiting for Google's bureaucracy to work out Kleos Music's production release, we've been wondering: What should our next app be? It might seem like a rather simple question, but it hides a complexity that only you and I, fellow developers, understand. Will the app be useful? Will people want it? Is the problem important enough? Are we going to spend months building something that ends up being used by five people?

So I decided to share kleosvic's "framework" on how to approach an idea. It's nothing revolutionary, and definitely not a guaranteed formula for creating a successful app, but it can help you think about an idea before opening your IDE and spending the next three months building it.

Some things to clear out before we start

Make apps around an existing idea

Not every idea needs to be unique. You can be unique in the way you turn that idea into an app. As you're used to hearing, Amazon wasn't the first bookstore, Facebook wasn't the first social network, and Google wasn't the first search engine. Being first doesn't automatically make your product the one people will choose.

There are already thousands of apps solving thousands of problems, and that's actually a good thing. If people are already using something to solve a problem, you at least have some evidence that the problem exists. Instead of always trying to invent a completely new category, look at what's already out there and ask yourself what could be done better.

Maybe the existing solutions are too complicated, too expensive, too slow, badly designed, or simply don't work well for a particular type of user. You don't need to invent something nobody has ever seen before. Sometimes you just need to take an existing idea and execute it in a way that makes more sense for the people you're trying to help.

Run from big ideas

I'm not saying you should stop being ambitious. I'm saying that you should find a small problem to fix and build around that, instead of immediately trying to build the next huge SaaS, the next social network, or the next AI company.

Starting small makes everything easier. A small problem is easier to understand, easier to validate, and much easier to build. You can put something in front of people, see what they think, change it, and repeat the process without spending six months building something nobody asked for.

And if people actually care about it, you can always make it bigger later. You don't need to know what the company will look like in five years before writing the first line of code. In fact, trying to figure that out beforehand will probably make you build things you don't even need later.

Touch grass

Seriously. A lot of ideas don't come while you're sitting in front of your computer trying to think of ideas. They come from actually living your life. Go to university, go to work, travel, play games, talk to people, use other people's apps, and pay attention when someone complains about something.

Developers tend to notice developer problems because they're the problems we experience ourselves. That's useful, but it can also make us think everyone has the same problems we do. They don't. Sometimes the best idea is something completely unrelated to technology that you notice because you happened to be there when someone was struggling with something.

You don't need to spend an entire afternoon brainstorming startup ideas. Just live normally and pay attention to things that seem unnecessarily complicated. You might find something much more interesting that way.

The framework

The framework can be summarized into four phases: Pain → Solution → Filter → MVP. The idea is to go through them in order, but not to treat them as a strict methodology. They're simply four questions that help you decide whether an idea is worth your time.

Pain

You should start with a problem, not an app. Pay attention to things that are annoying, take longer than they should, have to be done manually, or make you think there has to be a better way of doing this.

The problem doesn't have to be huge. In fact, a small problem can be a much better starting point, especially if you can understand it clearly. What matters is that the problem actually exists and is important enough for someone to want to solve it.

It's very easy to come up with a solution and then try to convince yourself that there must be a problem that justifies it. You might think an idea is really good, but that doesn't mean anyone needs it. One of the most interesting signals is when people are already trying to solve the problem themselves.

Maybe they're using a spreadsheet, a bunch of notes, a WhatsApp group, several different apps, or some completely ridiculous manual process. It doesn't matter if their current solution looks strange to you. What matters is that they're investing time and effort into dealing with the problem. They've already decided that the problem is worth solving; they just don't have a good solution yet.

You should also look at how often the problem happens. Something that annoys someone once every two years probably isn't a very good reason to build an entire app around it. Something that happens every day, on the other hand, gives people a much more natural reason to keep using your product.

And if you experience the problem yourself, even better. You already understand what makes it annoying and don't have to start by guessing what the user wants. That doesn't mean you should assume everyone has the same problem, but at least you have a starting point.

Solution

Once you have a problem, you can start thinking about how to solve it. This is where I think developers often get things backwards: we start with an idea for an app and then try to find a reason for that app to exist. It's much easier to do it the other way around. Start with the problem and ask yourself what could actually make it easier.

The first solution doesn't need to be complicated. It doesn't need an AI assistant, ten integrations, a social network, a recommendation system, and a beautiful dashboard. It just needs to solve the problem. If you can remove the problem with something incredibly simple, that's usually much more interesting than needing to build a huge system just to make the idea work.

You should also look at how people are currently solving the problem. If there are already apps doing something similar, use them. Look at what they do well and, more importantly, what their users complain about. Read their reviews, talk to users if you can, and pay attention to the small things that make the experience frustrating.

Existing solutions aren't necessarily a reason to abandon an idea. In fact, they can be one of the most useful things you have when starting out. If people are already paying for a solution but constantly complain about it, you've learned two important things: there is a problem, and there are people willing to pay to solve it.

Maybe the market doesn't need another app. Maybe it needs a better version of one that already exists. And that's perfectly fine. You don't need to create a completely new category to create something people want.

Filter

At this point you have a problem and a possible solution, but that still doesn't mean you should build it. This is where you need to be a little critical of your own idea, because it's very easy to get attached to something you've been thinking about for a long time.

First, ask yourself whether the problem actually matters. There's a difference between something that would be nice to have and something people actually want to solve. Then look at how often it happens. If the problem happens every day, there's a natural reason for someone to keep using your product. If it happens once a year, it will be much harder to justify an entire app around it.

You should also ask yourself whether people are already doing something to solve it. If they're doing absolutely nothing, that isn't necessarily bad, but it should make you wonder why. Maybe you've found a problem nobody has noticed yet, or maybe nobody cares enough to do anything about it.

Another interesting filter can come from something we talked about in our last post about Google Play Closed Testing. If you're developing an Android app, the closed testing phase can give you some useful information about whether people actually care about what you've built. If your testers repeatedly drop off before you can finish the process, or stop using the app shortly after you tell them that you've met the testing requirements, that can be a signal worth paying attention to.

Of course, you shouldn't treat this as absolute proof that the idea is bad. Testers can have their own reasons for leaving, and a small group of testers doesn't necessarily represent your target audience. But if you constantly have to convince people to keep testing the app and, as soon as they know the process is complete, they no longer have a reason to come back, at least ask yourself whether you're actually solving a problem they care about.

The same idea applies outside closed testing. If someone tries your product once because you asked them to and then never opens it again, that's information. If they keep coming back without you having to remind them, that's information too. Engagement alone doesn't prove that you have a great product, but the absence of it can be a useful signal when combined with everything else you're seeing.

You also need to consider whether you can realistically build the solution. An idea can be great in theory but depend on data you can't access, infrastructure you can't afford, or technology that simply isn't available to you. That doesn't necessarily mean you should abandon the idea. Sometimes you just need to reduce the scope.

The important thing is not to confuse the size of the idea with how much you need to build initially. You don't need to build everything to find out whether something is useful. You just need enough to test the assumption you're making.

MVP

This is where you can finally start coding. The MVP should be the smallest version of your idea that lets you test whether your solution actually works. I think this is where the term MVP gets misunderstood quite often: it doesn't necessarily mean building a terrible version of the final product.

It means building only what you need to answer the question you have right now. If you're making a productivity app, you might not need a mobile app, a desktop app, a browser extension, and an AI assistant. Maybe you just need the core functionality that solves the problem.

The same applies to pretty much anything else. If you're making a social network, you probably don't need every social feature you can think of. If you're building a marketplace, you don't need every payment method, account type, and recommendation system from day one either.

The less you build, the sooner you can put it in front of someone. And that's important because you don't really know whether your assumptions are correct until someone actually uses the product. You can spend weeks discussing how something should work, but a real user can teach you more in five minutes.

Then listen

Once you have the MVP, give it to people. This is probably the most important part of the whole process because you're no longer just making assumptions. You have something real that people can interact with, and that gives you information you simply can't get by thinking about the idea on your own.

Pay attention to what people actually do with the app, not just what they tell you about it. Someone telling you that your idea is cool is nice, but it doesn't tell you much. Someone using it every day tells you much more. The same goes for criticism: if someone tells you something is confusing or that they're missing a feature, don't immediately dismiss it just because it wasn't part of your original plan.

Sometimes you'll find that people use your app in a completely different way than you expected. They might ignore the feature you considered the most important and spend all their time using something else. They might ask for something you never considered. These aren't necessarily problems; they're pieces of information that can help you understand what your product should actually become.

The goal isn't to prove that your original idea was right. The goal is to find out what's actually useful. Your original idea is just a hypothesis, and the product is how you test it.

Build, learn, repeat

And that's basically the whole framework: Pain → Solution → Filter → MVP. Find something that is actually annoying, think of a way to solve it, make sure the problem is worth solving and the solution is realistic, and then build the smallest version you can.

From there, you learn from what happens and iterate. Maybe the idea works and you can keep expanding it. Maybe the problem is real but your solution isn't good enough. Maybe you discover a completely different problem while building it. Or maybe nobody cares.

And that's fine too. Finding out after two weeks is much better than finding out after six months. The goal of an MVP isn't to prove that your idea is going to become a huge company. It's to find out whether there's actually something worth continuing to build.

The important thing is not to fall in love with the idea itself. You're not trying to prove how clever you are for coming up with it. You're trying to build something that is useful to someone, and sometimes that means changing the idea you started with.

There are probably thousands of problems around you that could become apps. You just have to notice them. So before you open your IDE and start building the next big thing, go outside for a while, talk to people, use things, get annoyed by things and, most importantly, live your life.

You might come back with a better idea.