Most projects that fail don't fail because of programming. They fail because of an assumption nobody checked in advance: that people actually have the problem, and that they'll actually use the proposed solution.
Finishing an app is not the same as validating interest. You can have a finished app and still not know whether anyone wants to use it.
What you want to validate
Before choosing a test, name the question you're looking to answer. These are four different things, and each is validated differently:
Does the user have that problem? Is something holding them back today enough that they want to solve it?
Do they understand the proposed solution? Do they grasp, without explanation, what the app wants from them?
Can they actually use it? Can they get through the whole flow on their own, without your help?
Do they have a reason to pay for it or roll it out at their company? Is the change significant enough that they'll give up their current way of doing things?
If you pick one of these questions, the test stays simple. If you try to validate all four at once, what you end up building is a complete product.
You don't always have to start with programming
Depending on the question, far less than development may be enough:
Interviews with the people affected — to find out whether the problem exists and how they solve it today.
A walkthrough of the flow — a sketch or screenshots explaining how it should work.
A clickable prototype — to check whether people understand the flow and don't get stuck.
A functional first version — when you need to know whether people will actually use it in real work, with their own data.
Not every assignment needs custom development. Some things can be solved by configuring existing tools, and custom development only makes sense where off-the-shelf tools fall short. If a question can be answered without programming, that's a cheaper route to the same decision.
Pick one main scenario
A wish list of features usually has twenty items. For a test, you need one flow from start to finish.
This question helps: what does a person need to be able to do to get value from the solution today? Everything that isn't part of that one sentence belongs to a later stage.
In practice this means: pick one task, one type of user, and one path through which they complete it. Settings, edge cases, dashboards and a second role can wait.
Decide in advance what you'll track
The most common mistake in testing is treating praise as a result. "This is a great idea" isn't data — it's politeness. What you can actually track is behavior:
Could the user complete the task?
Where did they need help, or where did they get stuck?
Did they come back to the solution the next day, when nobody was watching?
Do they have a reason to use it instead of their current approach?
Decide what counts as a sufficient answer before the test, not after it. There's no universal percentage or threshold that applies to every project — it depends on how many people are affected and what decision you're basing on it.
Example scenario: testing an order-management tool
The following is a test design, not a measured result. It's an illustrative example.
Test brief: a staff member gets a regular order and, without your help, has to:
create it in the app;
assign it to a colleague;
check its status two days later without having to call anyone.
What's observed: at which step people get stuck, what data they're missing, whether the assignment to a colleague really works from the recipient's side, and whether the last step really replaces a phone call.
The result only has value once it's been genuinely tried out with people from the company. Until then, it's a hypothesis.
What to do after the test
The result isn't a "yes" or a "no." There are four possible outcomes:
Continue — the assumption held up, add the next scenario.
Change the scope — the solution makes sense, but something else deserves priority first.
Adjust the assumption — the problem exists, but users see it differently than you expected.
Postpone development — as it stands, there's no reason to invest further for now.
The fourth outcome is also a successful test. It saves the money you'd otherwise spend on features nobody needs.
The goal of a first version isn't to prove that the whole business idea will definitely succeed. It's to let you test a specific assumption and decide what's worth developing next.
And what about the 21-day timeframe?
Within 21 days we deliver a first working version in a scope we agree in advance. That's a commitment to delivering the agreed scope, not a guarantee that your market assumption will hold up. Only a test with real users can show that.
We cover how scope and price are determined in the article How much does the first version of an app cost, and where can you reasonably save. For technically uncertain solutions, see also A proof of concept is not production.
