An app idea feels wonderfully efficient when the work exists only in your head. Build the feature. Add a subscription. Find users somewhere on the internet.

The expensive word in that sentence is “somewhere.”

Before building, separate three questions: does someone need the result, can you deliver it reliably, and can you reach them repeatedly? A prototype that tests only the second question can be technically impressive and commercially useless.

Deliver the result once

Imagine a meal-planning app for people who finish work late. You could spend a month building recipe search. Or you could give five willing participants a week of practical dinner plans using their actual schedules, equipment and dietary constraints.

This is a hypothetical research exercise, not evidence that meal planning is a good business. Its advantage is that the awkward details arrive early. One participant shops only on Sundays. Another shares a fridge. A third doesn’t want variety; they want fewer decisions.

Record where the plan gets used, changed or abandoned. Compliments are pleasant. A person opening your plan while standing in a supermarket is more informative.

Ask about yesterday

“What features would you like?” invites a wish list. Ask what happened the last time they had the problem. What did they try? What did it cost? Who else was involved? If they can’t remember a recent instance, investigate whether the need is frequent enough for the business you imagine.

Don’t turn five conversations into a market-size claim. Use them to sharpen the next experiment.

Price the work you keep avoiding

The prototype should expose operating costs too. How much manual cleanup did the result need? How many questions arrived afterward? Which exceptions would require an expensive model, a human response or a complicated integration?

A feature that takes ten seconds in a demo may generate an hour of support when it fails.

Choose a stopping rule

Write one before you see the results. For example: continue only if participants use the result on a real task and at least some choose to return without repeated reminders. Set the threshold to suit the experiment; there is no universal magic number.

If the test works, build the smallest part that removes repeated manual effort. If it fails, change the audience or the promise before polishing the interface.

The first version of your app doesn’t need an app store listing. It needs a job worth coming back for.