How to validate an app idea before you build it: 7 steps (2026)

By Sigsten Gustavii· 27 October 2026· 8 min read

You validate an app idea by getting a real version of it in front of the people it is for, and watching whether they use it more than once.

Most app ideas fail quietly: not because they were built badly, but because nobody needed them enough to come back. Validation is how you find that out cheaply, before months of work. This guide gives you seven steps, from a one-sentence problem to a prototype people use, and the signals that tell you to keep going, change course or stop.

Why validate before you build

Building is the expensive part of an app, in money or in time. Every question you can answer before building makes the build smaller and better aimed. Validation is not a guarantee of success; it is a way to fail cheaply and early on ideas that will not work, and to go in with confidence on the one that might.

It matters more for an App Store app than for a personal one. If you are making an app just for yourself or your family, the only person to convince is you. Our page on personal apps is about exactly that kind of app.

Step 1: Write the problem in one sentence

Before features or screens, write who has the problem and what it costs them. "Runners forget to drink enough water on long training days" is a problem. "A water app with AI and social features" is a solution looking for one.

• Who exactly? Not "everyone": a group you could find and talk to this week.
• What do they do today? A notes app, a spreadsheet, a paper list, nothing at all.
• Why is that not good enough? Too slow, forgotten, too expensive, too complicated.

Step 2: Talk to people who have the problem

Find five to ten people who match the sentence and ask them about the last time the problem happened, not about your app. People are kind about ideas and honest about their own habits.

• Ask about the past: "When did this last happen? What did you do?"
• Ask what it cost them: time, money, stress.
• Ask what they have tried: if they have tried nothing, the problem may not hurt enough.
• Do not pitch. The moment you describe your app, the answers stop being useful.

Step 3: Check the App Store

Search the App Store for the words your people would use. Competition is usually a good sign: it means the problem is real. What you are looking for is a gap.

• Read the one- and two-star reviews of the top apps. They are a list of what people want and are not getting.
• Note what the apps charge, and how.
• Look for apps that are too broad. A focused app for one group often beats a general one.

Apple's own guidelines are a check here too: guideline 4.3 turns away apps that copy others, and Apple's App Review page lists "not enough lasting value" among common issues. An app that does one thing well for a defined group passes that test better than a clone.

Step 4: Define the smallest useful version

Write down the one thing the app must do well, and the two or three screens that do it. Everything else goes on a later list. A smaller version is faster to build, easier to test and clearer to explain. If it is not useful at this size, more features will not save it.

Step 5: Build a working prototype

This is the step that has changed most. A prototype used to be a clickable mock-up, because a real app took weeks. In 2026, an AI app builder can make a real, working app from a description in the same session. That matters for validation, because people react to a real app differently from a picture of one: they try to use it, and you see where they get stuck.

Step 6: Put it in people's hands

Give the prototype to the people from step 2. Then watch, do not explain. Where do they tap? What do they ignore? Do they finish the main task?

• In person or on a call: share your screen with the app running on a live iPhone in your browser, and let them tell you where to tap.
• On their own phones: with Apple's Developer Program, TestFlight lets you invite up to 100 people on your team and up to 10,000 outside testers, by email or a public link. Outside testers need a build approved by App Review for TestFlight. Our post on testing an iPhone app without an iPhone covers the other options.

Step 7: Measure whether they come back

The strongest signal is not what people say; it is whether they open the app again a few days later without being reminded. Ask them, a week later, whether they used it, and what for. Then decide:

Validation mistakes to avoid

• Asking friends whether they like the idea. They will say yes. Ask strangers about their habits instead.
• Counting compliments instead of repeat use. "Cool app" is not a signal; opening it again next week is.
• Building the full feature list before anyone tries it. Each extra feature delays the moment you learn something.
• Testing only with yourself. You know how the app is meant to work; nobody else does.
• Ignoring a weak result. A prototype nobody uses is information, not failure. Change the problem or the solution, and test again.

How to validate an app idea with Borel, step by step

Borel turns the prototype step from weeks into a day, and the prototype is the real app, written in native Swift, so nothing is thrown away if the idea works.

1. Write your one-sentence problem and the smallest useful version.
2. Describe it to [Borel](/signup), free with 5 credits a day, in a message like the one below.
3. Try it yourself on the live iPhone in your browser, and fix what is confusing with plain-language changes.
4. Show it to your people by sharing your screen, or put it on your own iPhone with Borel Companion on Pro and hand them the phone.
5. Give it to testers through TestFlight once you have joined Apple's Developer Program: Borel's Publish flow uploads the build, and it shows up in TestFlight.
6. Change it based on what you see, version by version. Every change is saved, so you can go back.
7. Publish when it earns it, from the same Publish flow.

A water tracker for runners on long training days: one tap logs a glass, the screen shows how much is left for the day based on my run length, and a reminder fires every 45 minutes during a run.

Testers keep missing the log button. Make it a large round button in the middle of the screen, and show today's total above it.

The bottom line

Validating an app idea means proving that people have the problem, try your solution and come back to it, as cheaply as you can. Talk to people, read the App Store, define the smallest useful version, and put a working app in their hands. If you want that working app today rather than in a month, start free on Borel: describe it, try it on a live iPhone, and show it to the people it is for.

I believe a working app in someone's hand teaches you more than any survey. If you test an idea this way, tell me what you learned.

– Sigsten

Make your iPhone app in Borel

Describe the app you want and see its first screens before you pay anything.