Start here.
Speak with people who face the problem, learn how they handle it now, and test one useful task before commissioning the full app. Look for specific examples and a willingness to try a clear next step. Treat compliments, signups, actual use, and willingness to pay as different kinds of evidence.
- Choose the question that could most change your decision before designing a trial.
- Include people who might decide against your idea, not only those who already encourage you.
- Write down what would make you stop or change direction while you can still make that choice cheaply.
Whose problem would the app solve?
Start with a person and a difficult moment you can describe. “An app for small businesses” leaves too much open. Someone who is trying to fill a cancelled place in tomorrow’s workshop gives you a more specific situation to investigate.
Imagine an app that helps independent workshop organisers offer empty places to people on a waiting list. This is an invented planning example. It is not a business we have researched or a product we have delivered for a client.
There are already two people to understand: the organiser trying to fill the place and the person deciding whether to attend at short notice. If you expect the organiser to pay, speak with whoever would make that purchase as well as whoever would use it.
Write down the problem you think matters, who faces it, and what they do today. Keep those as questions to investigate. You do not need a logo or a finished feature list to begin.
What should you ask potential customers?
Speak with people who currently face the situation you have in mind. Start by asking about something that happened, before explaining your proposed app. Give them room to describe the parts you have misunderstood.
For our workshop example, you could ask: “Tell me about the last time someone cancelled close to the date.” Follow with what they did next, who helped, and whether they managed to fill the place.
You might learn that contacting people is easy but keeping track of who has accepted is difficult. Or that cancellations are unusual and another problem matters more. Either answer helps you decide what to investigate next.
Ask permission before recording a conversation. If someone can show an example, use a version without other people’s private details. You are trying to understand the work, not collect a customer database.
A simple set of follow-up questions can keep the discussion concrete:
- What happened the last time?
- What did you try, and where did it become difficult?
- What happens if you leave the problem unsolved?
- What do you already use or pay for to handle it?
What can you try before building the app?
Choose the unanswered question that most affects whether the idea is worth pursuing. If you do not know whether attendees want last-minute places, a polished organiser dashboard will not answer that question.
With a willing organiser, you might try a small, clearly explained waiting-list service using their existing way of contacting people and a simple record of responses. Agree who will do the work and what the trial includes. Do not describe it as an automatic service if a person is doing it.
If the uncertainty is whether people understand the offer, a few connected sample screens may be enough to try. Ask someone to complete a realistic task with made-up bookings. Watch what they do and where they need help, rather than talking them through every screen.
Keep the trial small enough to change. You can investigate whether the service is useful without first building every account screen, payment option, and notification you can imagine.
What counts as useful evidence?
Keep what someone said separate from what they did. A person can sincerely like your idea and still have no reason to use it. Someone who tries the task may find it useful while being unable to approve a purchase.
The table below is a planning aid, not a scoring system or a set of results. It shows how each observation can inform a different question. None proves a business will succeed.
| What you observe | What it helps you understand | What remains unanswered |
|---|---|---|
| “That sounds useful” | How someone reacts to your explanation | Whether the problem matters enough to act |
| A recent example of the problem | What happened and how they dealt with it | Whether your proposed solution would help |
| An email signup | Interest in hearing more | Whether they will try, use, or pay for the service |
| Someone completes a trial task | How the idea works for that person in that situation | Whether they would return without your help |
| Someone agrees to discuss a paid trial | An opportunity to clarify the buyer, offer, and terms | Whether an agreed purchase and useful ongoing service will follow |
How do you judge the response fairly?
Record who had the opportunity to try, what you offered them, and what happened next. Include people who declined or did not finish. A list of enthusiastic replies without that context can leave you with an incomplete picture.
For the workshop trial, distinguish organisers who agreed to talk, those who tried it for an actual event, and those who wanted to use it again. Also note the help you supplied. If you personally chased every response, that is work the future service would still need to handle.
Ask why someone stopped. They may have found the problem unimportant, misunderstood your explanation, needed a different feature, or simply had no suitable event during the trial. Those are different reasons and suggest different next steps.
Before expanding, write a short account of what you know, what you inferred, and what remains uncertain. Be careful about treating a small group, especially friends or existing supporters, as a picture of the whole market.
When is it time to pay for a build?
A useful next conversation starts with a specific audience, examples of a problem they care about, and a test that has helped you understand how they might use your solution. You should also have a clearer view of who would pay and why.
That does not mean you need certainty before doing anything. It means choosing a next investment that matches what you have learnt. You might commission a limited demonstration, test a revised offer, or build a first version for a small group.
You can also decide to stop. If people already have an adequate solution or the problem rarely matters, finding that out before a full build is useful work.
Bring the evidence and your open questions to a software partner. Ask them to explain which uncertainty the proposed work will reduce, what you will receive, and what decision you will be able to make afterward. Our first-version and quote-comparison guides can help with that next step.
Bring what you have learnt, even if it is untidy.
Notes from a few real conversations can make a project discussion more useful than a long list of possible features.
- Who you spoke with
- Describe how they fit the audience you have in mind and whether you already knew them.
- What surprised you
- Keep the answers that challenged your idea as well as the ones you hoped to hear.
- What you showed
- Bring the sketch, sample task, or description people actually saw, so their reactions have context.
- What is still uncertain
- Name the question you need help testing before deciding whether to commission a build.
A couple of common questions.
How many people should I talk to?
There is no interview count in this guide that guarantees a good decision. Start with a manageable group who actually face the problem. If their situations differ, or a new concern could change your plan, speak with more people from that group before drawing a broad conclusion.
Should I start by paying for adverts?
First decide what an advert would help you learn. It might test whether people respond to a particular description, but it will not explain their reasons on its own. If you choose to run one, set a spending limit, make the offer accurate about what exists, and plan how you will follow up.