How to validate an app idea before you invest

An app idea feels obvious to the person who has it. That is its biggest risk. The certainty that "everyone needs this" is what leads to spending months and budget building something nobody downloads afterwards, and the worst part is that it could have been known in advance.

Validating an idea is not asking your friends if they like it. It is gathering evidence that someone has the problem, that it hurts enough, and that they would be willing to change what they do today for your solution. And it can be done in weeks, on very little money, before writing a line of code.

What validating actually means

There are three questions, in order, and each has to be answered before moving to the next:

1. Does the problem exist? Someone, today, loses time or money over the thing your app will solve.
2. Does it hurt enough? That person has already tried to solve it somehow: a spreadsheet, a chat group, an app they dislike. If nobody has tried anything, the problem does not hurt.
3. Would they pay, or at least change their habit? They are willing to drop what they use today, however bad, for your solution. Inertia is the strongest competitor.

What almost everyone validates is something else: whether the idea "sounds good". And almost all of them sound good.

The question is not whether people like your idea. It is whether someone is already trying to solve that problem, badly, with what they have.

Five ways to validate in weeks

1. Interviews with twenty people who have the problem

Not friends or family: people who have the problem. Twenty conversations of twenty minutes. The golden rule: do not describe your solution. Ask how they do today what your app would do, how long it takes, what they have tried, what they hate about it.

If after twenty interviews you cannot find five who describe the same pain in their own words, the idea needs adjusting before going further.

2. A landing page with a waitlist

A single-screen page that explains the promise and asks for an email. It costs a day and a domain. Then you drive people to it, with small ads, posts, direct messages, and measure how many leave their email.

There is no magic number, but if fewer than two out of every hundred visitors sign up, the message or the problem is not connecting.

3. Selling before building

The most honest test. Offer the product, with a price, before it exists. A pre-order, a deposit, a commitment. People lie in surveys and tell the truth with their credit card.

If ten people pay for something that does not exist yet, you have something. If nobody pays but everyone says they "love it", you have nothing yet.

4. Doing it by hand first

Before automating, deliver the service manually. If your app will connect customers with suppliers, connect them yourself over messages for a month. If it will generate reports, build them in a spreadsheet and send them.

You learn exactly what people need, which parts of the process matter and which do not, and you arrive at development with a scope that has already been tested with real customers.

5. A prototype you can tap through

Designed screens, no code, that navigate like the app would. Put it in front of ten people who have the problem and ask them to complete the main task without explanations.

It does not validate whether the problem exists, that is what the previous ones are for, but it validates whether your solution is understood. And it is what turns the idea into a concrete scope to build.

Which signals to take seriously

When to move from validating to building

When you can write in one sentence who has the problem, how they solve it today and what your app will do differently, and when you have a group of named people waiting to use it. At that point, the next step is not "the full app": it is the MVP, the smallest version that keeps that promise. We explain it in what is an MVP and how to build one that actually works.

And with validation done, the project is cheaper and faster, because the scope was decided by reality rather than assumptions. We cover that in how much it costs to build an app.

Frequently asked questions

How long should validation take?

Between two and six weeks. Longer than that is usually a way of postponing the decision.

Can I validate without spending anything?

Almost. Interviews and the manual service cost time, not money. The landing page costs a domain. Selling before building costs the awkwardness of asking for money for something that does not exist, which is the hard part.

What if my idea is so new that nobody has the problem yet?

Then it is a much bigger bet and you should know it. Ideas that work almost always solve a problem that is already being solved badly. If nobody solves it in any way, ask yourself why.

Can a development studio help me validate?

A good one, yes. It is part of strategy: before quoting, it will ask you these same questions and propose a prototype or a landing page before the full app.

---

At tēo studio strategy comes before code. If you have an idea and do not know whether to build it, tell us about it: we will tell you what we would validate first, how, and what the minimum scope would be if validation goes well.