How to validate an app idea when you're building it solo

Every guide on how to validate an app idea reads the same way. Run a survey, put up a landing page, talk to twenty strangers, and only then write a line of code. It is sensible on paper, and I have watched it quietly become a way to stall for months without learning anything real. I have built three small apps on my own now, and not one of them started with a survey.

The checklists get one thing right and one thing wrong at the same time. They are right that most ideas which feel brilliant in the shower do not survive contact with real people. They are wrong about how you find that out. Most of what gets called validation is just people being polite to you.

Most validation is people being nice to you

Ask a friend whether they would use your app and they will say yes. Ask a stranger in a survey and they will tick the box that makes them look reasonable. Nobody wants to tell you your baby is ugly, and almost nobody can predict what they will actually do next month. So you gather a pile of yeses, feel validated, build the thing and launch it to silence.

The only signal worth much is action. Someone handing over an email address, joining a waitlist, replying to a post to ask when it is ready or, best of all, putting down a deposit. Everything short of that is an opinion, and opinions about apps that do not exist yet are close to free.

Start with something you would actually use

My honest first filter is almost embarrassingly simple. I only build things I want for myself. Luna Journal came straight out of my own frustration with journaling apps: too many taps before I had written anything, my entries locked inside someone else's silo, and typing far too slow for how fast a thought moves on a walk. I was not guessing whether that problem existed. I was living it every day.

Building for yourself has one big advantage. You are the single user you can interview honestly and watch for free, forever. You know precisely where the friction sits because you feel it. The catch, and it is a real one, is that an audience of one proves the problem is real for you and nothing more. Plenty of people have built lovely solutions to problems only they had.

So I treat my own need as a reason to start, not as proof I am done. It gets me to a working thing I use daily, which is already worth more than a hundred survey answers. Then I go looking for evidence that I am not the only one who wants it.

The demand is already sitting in the app stores

You do not need a study to validate an app idea. People have been telling Google and the app stores what they want for years, and that record is free to read before you write a line of code.

• Search demand for the problem, not your product. People do not search "Luna Journal", they search "voice journaling app" or "how to journal without typing". A keyword tool shows you roughly how many do it every month.
• A crowded category is usually good news. An empty one often means there is no money in it, not that you have found untapped genius. If ten apps already exist, people are paying to have that problem solved.
• Competitor reviews are a free feature spec. The one and two star reviews are users telling you exactly what today's apps get wrong. A good chunk of my roadmap is just complaints other apps decided to ignore.
• What similar apps roughly earn. Ballpark download and revenue estimates are enough to tell you whether a category can feed one more small app or is already a bloodbath.

This is where I spent real time on Meridian Clock. The alarm and world-clock space is huge and old, which put me off at first, until the reviews pointed at a specific, unfixed complaint: alarms that quietly die when you cross a timezone or restart your phone. A crowded market with an angry, ignored corner is about as good a sign as you get.

The cheapest test is the smallest real thing

Once a problem looks real for more than just me, I want the smallest test that produces action instead of opinion. Usually that is a plain landing page: what the app does, who it is for and the one problem it kills, with a single field to be told when it launches. No spin, just the honest pitch.

The number that matters there is not how many people visit, it is how many read it and still hand over an email. A page plenty of people see and nobody signs up for has told you something useful and a little painful. Far cheaper to learn that from a page than from six months of building.

A page plenty of people see and nobody signs up for has told you something useful and a little painful.

Building in public does a similar job. You post what you are making and watch whether anyone replies asking for it, because a reply costs a small amount of effort and effort is the currency that counts. Silence is data too, even when it stings a bit.

When to trust yourself, and when to get outside proof

How hard you validate should scale with what a wrong answer costs. A small, private tool I will build in the evenings and use myself barely needs more than my own itch and a quick check that other people complain about the same thing. If I am wrong, I have lost a few weekends and ended up with an app I use anyway.

The moment real money, a launch budget or months of full-time work go in, or the moment the intended user is not me, the bar rises. Then I want action-based proof before I commit: a waitlist that actually fills, people asking when it ships, a handful who would pre-pay. Not because a checklist says so, but because I can no longer let my own gut stand in for a stranger's wallet.

The short version

You do not validate an app idea by running the perfect study. You do it by staying honest with yourself. Build from a problem you genuinely have, then check the app stores and the search numbers to see whether the world quietly agrees with you. Put up something small and real, and watch what people do rather than what they say. Match how much proof you demand to how much a mistake would cost. Do that and you sidestep both traps: the months lost to validation theatre and the silent launch of something nobody but you ever wanted.

If you keep one thing, keep the action test. Next time someone tells you your idea is great, thank them, then quietly set it aside until they have done something that cost them a little effort. That is the only yes worth building on.

Benjamin

Founder & sole developer, Novaire Digital