A friend says your app idea sounds useful. You imagine a name, a dashboard and a long feature list. But one question remains unanswered: will someone use it when they have real work to do?
Checking demand means gathering evidence about a problem and people’s willingness to try a different way of solving it. You can begin before you know how to code. A conversation, a paper example and a small manual trial can reveal what your first product should do, or why you should change direction.
This guide focuses on a reusable product you might develop for your own business. It is not a guide to finding freelance clients, and it does not promise that a few interviews will prove a business opportunity. The aim is a better next decision with limited effort and risk.
Start with a situation you can investigate
Choose a group you can reach respectfully and a task you can understand. “Software for all small businesses” leaves you with too many assumptions. “A tool that helps a neighbourhood repair shop prepare a clear collection list” gives you something specific to investigate.
Write a first hypothesis, which is simply an idea you intend to check: “People in this group struggle with this task often enough to consider another method.” Keep the proposed solution out of the first sentence.
A problem might support a personal tool, an internal business system or eventually a product used by several organisations. These are different outcomes. A tool that helps one family shop can be worthwhile without establishing a wider market.
The GOV.UK discovery guidance recommends understanding likely users, their current process and their difficulties before planning a service. Its public-service context differs from a small business, but the research questions provide a useful starting point. User research in discovery
A fictional product idea to investigate
Sana, a fictional student in Faisalabad, notices that small tailoring workshops sometimes prepare collection information in different places. She imagines a simple product that turns an approved list of finished orders into a clear daily collection sheet.
She has not established that workshops need it. Her imagined solution may duplicate a notebook that already works. The actual difficulty might be unfinished alterations, not organising the collection list.
Sana writes a narrow question: “How does a workshop decide which finished items are ready for collection today?” She can explore that without asking for customer names, phone numbers or private order records.
Her first sketch uses invented order codes such as T01 and T02. It does not send messages, collect money or change a workshop’s real orders. These boundaries let her investigate the workflow without presenting an unfinished product as operational software.
Ask about the last time the task happened
Instead of opening with “Would you use my AI app?”, ask the person to describe a recent occasion. Useful questions include:
- When did you last prepare a collection list?
- What did you look at first, and what happened next?
- Which part needed a second check?
- What do you do when an item is not ready after all?
- What tools or notes already help?
- Who uses the list, and who would decide to adopt a different method?
Ask permission before observing work or taking notes. Explain that you are learning about the process, not selling a finished system. Let people decline, and avoid recording private details you do not need.
If someone says “It takes too long,” ask what happened during a particular example. Do not turn an uncertain recollection into a precise statistic. Record a direct observation, a participant’s estimate and your interpretation separately.
Talk to people whose circumstances differ where practical: a person who works alone, someone coordinating with a colleague, or someone who prefers paper. A small convenient group can help you learn, but it does not represent every workshop in Pakistan or elsewhere.
Separate compliments from useful evidence
“You should build that” is encouragement. It does not tell you whether the person will change their routine. More useful evidence might include a recent example of the problem, an existing workaround or agreement to try a clearly described sample on a relevant task.
Even these signals have limits. Attending one demonstration does not establish repeated use. Repeated use does not establish willingness to pay. A person who uses the tool may not be the person who decides whether a business buys it.
Make an evidence log with four headings: what happened, what it suggests, what it does not establish and the next question. This prevents your confidence from growing faster than your evidence.
Figure 1. Each observation can answer one question while leaving another unresolved.
Offer a small honest trial
Suppose Sana’s conversations suggest that preparing a readable daily list deserves investigation. She offers to demonstrate a manually prepared sample using invented information. She says plainly that there is no working automated service yet.
She asks a participant to find the items marked Ready, spot an item put on Hold and explain what they would do next. If the person cannot interpret the sheet, adding AI will not fix the unclear status labels.
A later, permission-based trial could use appropriately minimised information in an agreed setting. Before that, Sana needs to decide what she will handle, who can see it and when the trial material will be removed. Staying with invented records is a reasonable choice while she is still learning.
The trial should answer one question, such as whether the layout helps the participant identify the correct collection items without Sana explaining each line. Avoid building login systems and automatic reminders merely to test a list layout.
Decide what would change your mind
Write the decision rule before the trial. Otherwise, it is easy to reinterpret every outcome as success.
For this fictional example, Sana’s exploratory rule is: continue investigating if participants can complete the sample task and can describe a recurring situation where the list fits their work. Revise if the task matters but the sample is confusing. Pause if the existing method is satisfactory or the proposed list addresses the wrong problem.
These are suggested project decisions, not statistical validation criteria. A small trial cannot prove market size or a future income level. Its value is in revealing whether another round of learning is justified.
Also record what would make the product impractical for you now. Perhaps users need reliable offline printing but you have only tested a screen. Perhaps supporting several people requires technical work you do not yet understand. Discovering that early helps you choose a smaller next experiment.
Figure 2. Decide in advance which observations would justify the next step.
Look at adoption as well as usefulness
A useful-looking output may still be difficult to adopt. Who enters the information? Does that duplicate existing work? Can the person use it on their available device? What happens when the internet connection is unavailable? Is the printout readable for the person collecting the items?
Ask rather than assuming answers based on a city, income level or job. Pakistani students and businesses differ, just as international users do. Language, script and device constraints belong in your research notes.
You can discuss willingness to consider a paid version without taking money or promising delivery. Ask who approves spending and what an acceptable trial would require. Treat any price discussion as an unresolved product assumption, not proof of revenue. This early exercise does not require deposits, contracts or financial projections.
Use this demand worksheet
Complete one page before adding features:
- User group: Who specifically performs the task?
- Recent situation: When does the problem occur?
- Current method: What already works, and what causes difficulty?
- Evidence: What did I observe, hear or merely infer?
- Small alternative: What can I demonstrate without a full application?
- Test task: What should a participant do without coaching?
- Decision rule: What would make me continue, revise or pause?
- Adoption barrier: What additional effort would my product create?
- Unanswered question: What must I investigate next?
Add a final line: “This evidence does not yet establish…” Complete it honestly. It might say repeated use, payment interest, accessibility or suitability outside the small group you met.
Frequently asked questions
Can I check demand without coding
Yes. You can investigate the current task and use a paper or manually prepared sample. Choose a format that can answer your question. Explain clearly when the process is manual so nobody mistakes it for an available automated product.
How many people should I interview
There is no universal number that proves demand. Start with a manageable group of relevant people, look for important differences and record what remains unknown. The quality and relevance of evidence matter more than reaching an arbitrary count.
Should I ask friends and family
They can help you practise your questions. Their feedback is more relevant if they actually perform the task. People who want to encourage you may be unusually positive, so seek evidence beyond general praise.
What if someone already sells a similar tool
Study whether the intended users know about it and why they do or do not use it. An existing alternative may solve the problem well. Your next step could be learning from that workflow rather than making another product.
Does a free trial prove people will pay
No. A free trial can reveal usability and interest under its particular conditions. Payment introduces a separate decision involving value, alternatives and approval. Do not convert trial participation into an earnings forecast.
What if my research shows little interest
Write down what you learned and pause or change the idea. You may have found a different problem, a narrower user group or a useful personal project. Avoid adding features merely to defend the original idea.
Your next step
Write one problem hypothesis and invite a relevant person to describe the last time they handled that task. Ask for a conversation, not an endorsement. Afterwards, separate observations from assumptions and choose one question a small sample could answer. Build only what that question requires.