How to Validate an App Idea Before Paying for Development

That feedback can be useful, but it is not enough to commission an app.

Ask:

• Does the person experience the problem?
• How often does it occur?
• What do they do today?
• What does the current workaround cost them?
• What have they already tried?
• What would make them change?
• What action would they take next?

The GOV.UK guidance on user research in discovery recommends learning who users are, what they are trying to do, how they do it now and what problems they experience before planning, designing or building a service.

That principle applies to commercial products too. Start with the problem and the existing behaviour, not the feature list.

Define the Audience and Problem

Before speaking to users, write a short problem statement.

A useful user need describes the person’s problem rather than prescribing a solution.

For example:

I need to compare suitable providers in one place so that I can make a confident decision without repeating the same research.

That is more useful than:

I need a mobile app with a provider directory.

The first statement can be tested through interviews and observation. The second already assumes the solution.

Conduct Interviews Without Pitching

Interviews are for learning, not persuading.

The GOV.UK guidance on in-depth interviews recommends using interviews to understand people’s circumstances, how they use services and what they need to achieve the right outcome.

Useful questions include:

1. Tell me about the last time you had this problem.
2. What were you trying to achieve?
3. What did you do first?
4. Which tools, people or processes did you use?
5. What was difficult or time-consuming?
6. What happened when the workaround failed?
7. Have you paid for or tried another solution?
8. What would make you change your current approach?
9. Who else would be involved in the decision?
10. What would you need to trust a new solution?

Avoid leading questions such as:

• Would you download this app?
• Do you like this feature?
• Would you pay £X for it?
• Would reminders make this easier?
• Do you think this is a good idea?

Those questions invite polite agreement. Asking about recent behaviour is more useful.

Do not treat every interview statement as a fact. Record what was directly observed or said, then separate your interpretation from the evidence.

Look for Patterns, Not One Perfect Quote

Early research can be messy. People describe the same problem differently. Some use different language. Some have unusual circumstances. Some are not actually part of the intended audience.

After interviews, group findings by:

• Repeated problem
• Current workaround
• Trigger
• Consequence
• User type
• Frequency or urgency
• Existing spend or effort
• Decision-maker
• Barrier to adoption
• Evidence that contradicts the initial assumption

Do not select only the comments that support the idea.

A useful research summary contains:

Validation is stronger when it exposes inconvenient evidence early.

Test Behaviour With a Prototype or Manual Service

Once the problem is clearer, test the proposed workflow without immediately building the full app.

Possible formats include:

• A clickable prototype
• A landing page with a clear action
• A manual service delivered behind a simple interface
• A spreadsheet or form that simulates the workflow
• A concierge process where the team completes difficult steps manually
• A technical proof of concept for a risky integration
• A small invitation-only test

The GOV.UK prototyping guidance recommends using prototypes to explore, share and test designs before committing to production code.

Choose the lightest test that can answer the question.

Do not make a prototype look more complete than the evidence supports. The purpose is to answer a question, not to create a polished advertisement.

Look for Commitment, Not Compliments

Commitment can take different forms depending on the product and audience.

Examples include:

• Agreeing to a research session
• Sharing access to a relevant workflow
• Introducing the decision-maker
• Providing realistic test data with appropriate safeguards
• Joining a pilot
• Signing up for a waitlist with a clear use case
• Paying a deposit or pre-ordering where appropriate
• Returning to complete another meaningful task
• Allowing the team to observe the existing process
• Making time for implementation or procurement discussion

The form of commitment matters. A casual email address may show interest, but it does not necessarily show urgency. A completed workflow, repeated use or commercial next step provides stronger evidence.

Do not manipulate people into commitment or create artificial scarcity. Explain what participation involves, collect only the information required and make it easy to withdraw.

For research involving people, the team should consider informed consent, participant privacy and how recordings or notes will be handled. The GOV.UK research guidance includes resources for getting informed consent and managing research data.

Test the Workflow Before the Features

An app idea may sound valuable because of its feature list. Validation should examine the full workflow around the feature.

Ask:

• How does the user discover the product?
• What information do they need before starting?
• What must they provide?
• What happens if the data is incomplete?
• Is another person involved?
• Does the user need to wait?
• What happens after the main action?
• What support is needed?
• What happens when the service fails?
• How often would the user return?

A solution can pass a feature test and still fail as a product because the surrounding process is too difficult.

For example, a person may want an easier way to submit information, but the real barrier may be finding the correct information, receiving approval from another person or understanding what happens after submission.

Test the journey from trigger to outcome.

Use a Validation Scorecard

A scorecard helps the team make a decision without allowing one exciting result to dominate the evidence.

The labels are not scientific measurements. They are a way to make uncertainty visible.

Decide: Proceed, Change, Pause or Stop

Validation should end with a decision.

Stopping is not wasted work. The GOV.UK discovery guidance recognises that research may show that moving forward is not the best decision. Learning this before a major build can protect time and capital.

Do not continue simply because research has already consumed money. The next question is whether further evidence is likely to change the decision.

What to Do Before Commissioning Development

Before requesting an app proposal, prepare:

• A defined first audience
• A clear problem statement
• Evidence from current or likely users
• A mapped core workflow
• A list of assumptions
• The riskiest assumption
• A proposed validation test
• A clear first-release outcome
• Known privacy, security and operational considerations
• A decision about what evidence would justify development

A development partner should be able to challenge the scope. If the brief treats every idea as essential, validation has not finished.

You can also read FlutterCraft’s product and engineering services to understand how discovery can connect to later delivery.

Conclusion

Validate the problem before validating the app.

Speak to people about recent behaviour. Understand current workarounds. Test the workflow with the lightest credible method. Look for commitment and repeat use rather than compliments. Record contradictory evidence and make a clear proceed, change, pause or stop decision.

The best outcome of validation is not always permission to build. It is a better decision.

For more practical guidance on MVPs, product discovery and digital investment, visit the FlutterCraft blog or join the newsletter at /newsletter.

Sources

• User research in discovery, GOV.UK
• Plan user research for your service, GOV.UK
• Using in-depth interviews, GOV.UK
• Making prototypes, GOV.UK
• Getting informed consent for user research, GOV.UK
• How the discovery phase works, GOV.UK
• Measuring the benefits of your service, GOV.UK