The feature list can keep growing while the most important question stays unanswered: will anyone use this product often enough to pay for it?
SaaS MVP development should produce evidence that helps you decide what to fund next. A small application can still be a poor experiment if it tests the wrong assumption. Conversely, some questions can be answered before a production application exists.
Start by identifying what would make the business fail even if the software worked perfectly. Perhaps customers will not share the required data. Perhaps the problem occurs too rarely. Perhaps the person who likes the demo cannot approve the purchase. Those uncertainties deserve attention before another feature goes into the backlog.
Write the assumption as something you can observe
“Small businesses need better reporting” leaves too much room for interpretation. Which businesses? Who creates the report? What happens when it is late or wrong? What do they do today?
Consider a hypothetical reporting product for account managers. A useful assumption might be that managers will connect their existing data and use a generated weekly report in an actual customer meeting. That is more demanding than asking whether they like the dashboard.
Separate the assumptions instead of hiding them in one large launch target:
- The intended user has a recurring problem worth addressing.
- The required data is available and usable.
- The workflow produces an outcome the user trusts.
- The buyer sees enough value to consider paying.
You may need different tests for each. A working integration does not demonstrate demand, and a promising sales conversation does not prove that an integration is feasible.
Choose the cheapest credible test for the uncertainty
An interview can reveal how work happens today. A prototype can show whether someone understands a proposed interaction. A manually delivered service can help test whether the output is useful. None is automatically a substitute for a product, but each can answer a narrower question.
The GOV.UK Service Manual describes using prototypes to test risky assumptions during alpha. That is guidance for public services, not a SaaS growth benchmark. The transferable principle is to investigate uncertainty before committing to production scope.
If your main risk is whether customers value a report, you may be able to prepare it manually from data they knowingly provide. If your main risk is whether a third-party API exposes the necessary information, a technical investigation is more appropriate than another polished mockup.
Be clear with participants about manual work and product limitations. Do not present a founder-operated process as proven automation. Also respect the sensitivity of any real customer data used during testing.
Define one complete useful journey
Once a working product is justified, choose the smallest journey that delivers the promised result. For the reporting example, that could mean connecting one data source, generating one report and letting the user correct it before sharing.
Supporting five integrations may broaden the market later. It also multiplies the number of ways the first test can fail. Start with the source used by the customers you intend to recruit, provided it gives you a representative test.
“Minimum” should refer to the breadth of the product. It is not permission to ignore essential access controls or lose customer records. A real-user pilot needs safeguards proportionate to what it handles, even if the interface is simple.
If you already have an AI-built prototype, our launch-readiness guide addresses the technical checks before customers rely on it. Those checks complement product validation; they do not replace it.
Decide how you will interpret the pilot before it starts
Write a short test brief with the intended participants, the task and the observation window. Include what would lead you to continue, change direction or stop.
Do not copy an activation percentage from an unrelated product. A daily collaboration tool and a quarterly reporting product should not be judged on the same return interval. Choose a window that gives the task a genuine opportunity to recur.
Track whether participants reach the useful outcome, whether they return when the need comes back and what assistance they require. Record purchase discussions separately from product usage. A participant who uses a free pilot enthusiastically has not necessarily accepted your pricing.
With a small group, individual behaviour can matter more than an impressive-looking percentage. Record the number of participants behind every rate and what made them eligible for the test. Avoid treating friends, staff accounts or people outside the target audience as evidence of demand.
Keep manual work visible in the economics
Founder assistance can help an early customer succeed. The danger is forgetting how much assistance it took.
Record onboarding calls, data cleaning and corrections alongside software usage. If every report requires substantial expert review, you need to understand whether the proposed price can support that work and whether customers accept the delivery time.
This does not automatically invalidate the product. It may point towards a higher-priced service, a narrower audience or a specific automation priority. What matters is making the dependency visible before promising self-service at scale.
The same applies to usage-based infrastructure or AI services. Estimate operating costs from the pilot’s actual workflow rather than assuming that each additional customer is almost free.
Use feature requests as evidence to investigate
When a participant asks for an export, ask what they need to do with it. The request may reveal that the report must fit an existing approval process. It may also be a preference that has little effect on adoption.
Distinguish a blocked task from a suggested improvement. If the user cannot obtain the promised result without the feature, it may belong in the next iteration. If it serves a different customer segment, adding it could make the current test harder to interpret.
Keep a record of who requested the change, the problem behind it and whether others encountered the same obstacle. Do not let the loudest participant silently redefine the product.
Make the next investment a decision rather than a habit
At the end of the pilot, compare the evidence with the assumptions you started with. Useful outcomes include continuing with a focused release, changing the workflow or deciding that more development is not yet justified.
Before approaching a development partner, prepare the target customer, the risky assumption and the journey you want to test. Include what you have already learned, including findings that contradict the original idea.
Five Bricks can discuss that scope before a broader build. Share the proposed pilot through our client intake form. For budgeting context, the web application development cost guide explains which requirements change the engineering effort. The estimate should follow the test you need, not determine the question you happen to test.