How to Build a Minimum Viable Product That Gets Used

Of 325,811 UK startups registered in 2020, only 47% were still operating three years later, and just 2% of those survivors had reached at least £1 million in turnover. Those figures don't show that building a minimum viable product guarantees success. They do show why it's risky to spend heavily before you've tested whether customers want the outcome you're offering.

Table of Contents

• Why Validation Should Come Before Features
  • Start with a decision, not a feature list
• Prioritising Features Around Your Riskiest Assumption
  • Build around the test
• Prototyping to Test Demand Before Writing Code
  • Watch what people do
• Choosing the Right Tech Stack for Your MVP
  • Treat AI as a workflow decision
• Launching and Measuring Real Usage
  • Read the evidence in order
• Running Short Iteration Cycles After Launch
  • Keep the next bet small

Why Validation Should Come Before Features

An MVP is a measured validation stage, not a smaller copy of the final product. It should let you test a specific business assumption with real users, then help you decide what to do next. That means agreeing on what evidence matters before development begins: activation, retention, conversion, revenue and support demand.

The UK startup figures provide a useful risk benchmark, not a verdict on any individual product. The same government evidence reports that UK business births fell from 337,000 in 2022 to approximately 316,000 in 2023, while the business birth rate declined from 11.5% to 11.0% (UK Government evidence on small businesses). In that environment, a focused first release can help a founder test a proposition while keeping development effort and cash under control.

That only works if the release tests something that could change a business decision. A polished interface isn't evidence of demand. Neither are positive comments from people who haven't tried the workflow, or a long feature list that assumes customers will pay later.

Start with a decision, not a feature list

Before building, write down the question the first release must answer. For example: Will the target buyer pay to make this task easier, and will their team use the product again? Then decide what observable evidence would support, weaken or disprove that idea.

Be specific about who needs to act and what they need to do. A product for an individual choosing a subscription may need to prove that users complete a core task and pay. A B2B product may need a buyer willing to fund a pilot, even if only a small group uses it at first.

Practical rule: If you can't name the decision that a piece of evidence will inform, you're not ready to build that feature.

An MVP also isn't permission to ignore reliability, privacy or the work required to deliver the service. It must be usable enough for a customer to try the promised value. If a product handles sensitive information, security and appropriate access controls belong in the test design, not on a distant roadmap.

You're ready to start when you can name the riskiest assumption, the people who can test it and the signal that would change your next move. The build should follow that test. The point is to learn whether the product proposition holds up, not to prove that the team can ship software.

Prioritising Features Around Your Riskiest Assumption

A booking-tool founder could spend months building calendars, payments, reports, staff permissions and integrations. But if the main uncertainty is whether customers will complete a booking through the tool, most of those features don't belong in the first release.

Start by listing the assumptions behind the product. Include the customer's problem, the core workflow, willingness to pay, repeat use, delivery costs and any operational or technical constraint that could block adoption. Then rank each assumption by two things: the damage if it's wrong and how cheaply you can test it.

Build around the test

Use a simple sequence to turn those assumptions into a scoped release:

1. Identify the riskiest assumption. If buyers may not pay, polishing the reporting dashboard won't resolve the biggest uncertainty.
2. Define the smallest test. Decide what a potential customer must be able to do for you to learn whether the assumption holds.
3. Choose only validating features. Include the booking flow if it tests whether customers can make a booking. Leave out features that aren't needed to run that test.
4. Remove everything else. Treat the backlog as a list of later options, not an agreement to build everything.
5. Release to learn. Specify what you'll measure and what outcome would change the plan.

For the booking tool, a first version might let a customer choose an available time and receive confirmation. If the founder can manage invoicing manually during the test, automated billing can wait. If customers need to connect an existing calendar before they'll try the workflow, that integration may be essential. The question is not whether a feature sounds useful. It's whether the test fails without it.

This separation matters for smaller firms, which often have fewer resources to spread across innovation work. In the UK Innovation Survey 2023, 36% of UK businesses were innovation active during 2020–2022, compared with 45% in the preceding survey period; the rate for SMEs was 36%, compared with 50% for large businesses (UK Innovation Survey results). Product innovation was reported by 19% of businesses, while business-process innovation was reported by 29%.

That evidence supports a practical choice: test the customer outcome before committing to a broad product build. The first release may be a customer-facing application, or it may be a focused operational tool that improves an existing workflow. If a feature doesn't test the riskiest assumption, it waits until evidence says otherwise.

Prototyping to Test Demand Before Writing Code

A founder scoping a booking product can learn a great deal before commissioning production software. They can map the customer's current process, sketch the proposed workflow, then turn it into a clickable prototype. A prototype won't prove that a production system works, but it can reveal whether people understand the proposed task and where the design gets in their way.

The founder creates a screen for choosing a time, another for entering details and a confirmation screen. Then they ask potential customers to complete one task using the prototype. They don't explain every button or rescue the person as soon as they hesitate. The friction is the useful part.

For a practical starting point, use wireframes to map the core workflow before adding visual polish. Keep the test focused. If the product's value depends on customers completing a booking, don't spend the session asking them to review a speculative reporting dashboard.

Watch what people do

Notice where someone pauses, which step they skip and what they ask without prompting. Do they understand what happens after choosing a time? Do they look for a way to change the booking? Do they ask when they can use the product with real customers, or whether they can pay for it? Such signals are more useful than a general “I like it”, though they still need follow-up before you treat them as proof of demand.

A prototype can also be paired with a concierge test. The customer sees a simple interface, while a person handles the work behind the scenes. For the booking tool, the founder might confirm appointments manually rather than automate scheduling immediately. That tests whether customers value the result before the team builds integrations and back-end processes.

Manual delivery isn't automatically the right approach. It can conceal costs or operational demands that would make the business unviable at scale. Track the work involved, the information people need to provide and where errors or delays occur. If the test requires a human to compensate for confusing instructions, fix the workflow before automating it.

A prototype has done its job when you can identify the next build decision it changes. Perhaps customers can complete the task but need a different confirmation step. Perhaps the workflow is unclear enough that you need to revise the concept before writing code. If every session ends with the same vague feedback and no change to your decision, sharpen the test. The purpose is to learn what to build next, not to collect compliments.

Choosing the Right Tech Stack for Your MVP

The first technical decision is what must work to test your riskiest assumption. A sign-up page needs little custom code. A product with permissions, payments or sensitive data needs tighter control, even at MVP stage. Choose the smallest build that can run the test and meet its real operating requirements.

A Webflow-style page can test whether a proposition draws enquiries. It cannot prove that a complex service works in a customer's day-to-day workflow. For that, build only the parts needed to run the test, such as account access or one payment route. A framework like Next.js may suit that job, but it is one option, not a default.

Write down the cost of being wrong before choosing tools. Check the time to change the product, integration requirements, security and data handling, code ownership, and the cost of moving away from a provider. A detailed guide to web application architecture can help you decide how components should connect and what to keep under your control.

Treat AI as a workflow decision

UK businesses vary in their use of AI. Government research found that 41% of businesses handling digitised data used AI technologies in 2025–26, including 51% of small firms, 58% of medium firms and 41% of micro businesses (UK Business Data Survey findings). Research involving UK micro and small businesses found that 21% used AI regularly, while 6% had embedded it across daily work. Cost, skills, privacy concerns and lack of time were among the reported barriers.

For an MVP, test one bounded task, such as drafting a reply or classifying a request for staff review. Set a pass condition: the output must save enough staff time to justify its cost, and a person must be able to catch errors before they affect customers. Decide what data the tool can receive, how staff correct mistakes, and how to stop using or replace the provider. These controls determine whether AI belongs in the test.

If your team lacks product or engineering capacity, an outside studio can scope, design and build the experiment. Compare its deliverables with the decision you need to make. Cut features that do not help test that decision, and agree who owns the code and can maintain it after launch.

The following video gives a visual overview of the build process:

Launching and Measuring Real Usage

A launch can produce plenty of sign-ups and little evidence of value. Track whether users complete the core task, return to do it again, pay, and achieve the outcome the product promises. Each action answers a different question.

Read the evidence in order

Move from stated interest towards evidence of a working commercial relationship:

• Problem interviews: People explain the problem and how they handle it now.
• Observed workflow pain: You watch where the task takes time, causes errors or gets abandoned.
• Paid design-partner commitment: A buyer commits budget, staff time or a signed pilot agreement.
• Repeat usage: Users return to complete the task, rather than just explore the interface.
• Measured outcome: The product reduces effort or errors in a way the customer can recognise.
• Renewal and referral: A customer continues the relationship or recommends the product.

These signals carry different weight. Interviews show how people describe a problem. Repeat use gives stronger evidence that the product fits their workflow. Payment and renewal indicate commercial commitment, though their value depends on the buyer and sales process.

AI uptake is a useful reminder that adoption alone does not prove business value. As noted earlier, UK businesses are experimenting with AI, but adoption figures do not show whether a specific product improves a workflow or creates enough value for a customer to renew.

In B2B, regulated and procurement-led markets, usage needs context. A compliance or training product may see infrequent use yet support a valuable contract. A free tool may attract many users without covering delivery and support costs. Keep usage, revenue and product-market fit as separate measures.

At launch, instrument the path from first visit to activation and repeat use. Track paid commitments, renewals and referrals separately. Record support requests and the customer outcome the product aims to change. For enterprise buyers, check whether procurement, data protection, accessibility, cyber requirements or integrations are blocking adoption. Those obstacles affect whether the product can be bought and used.

Running Short Iteration Cycles After Launch

Once users are working with the product, keep each cycle small and decision-led. A regular review helps the team compare what it expected with what happened, then decide whether to keep the current bet, change direction or stop. The exact rhythm matters less than reviewing evidence consistently and acting on it.

Before launch, define what would count as enough evidence to invest further, what would make you revise the proposition and what would lead you to stop. Without those criteria, enthusiasm can turn every weak signal into a reason to keep building. A team should also be willing to act on a negative result. Learning that a buyer won't pay is useful only if it changes what the team does.

A disciplined review can follow a simple rhythm:

• Gather feedback: Talk to users and check whether they completed the core task.
• Prioritise fixes: Choose the issue most likely to undermine the current test.
• Ship the next change: Make a focused change instead of expanding the product in several directions.
• Review results: Compare behaviour and customer outcomes with the criteria you set before the release.

A training platform with relatively few users could be succeeding if it has high-value contracts and customers renew. A free tool with much wider use could still be failing if customers won't pay and the cost of delivering the service makes the model unviable. Judge the product against its buyer, commercial model and intended outcome, not a universal usage target.

Keep the next bet small

Each cycle should test a clear reason for change. If users abandon a task, investigate the point of friction before adding features around it. If the product works but buyers can't approve a purchase, address the relevant procurement or security concerns before chasing more sign-ups. Resist turning every request into a commitment. One customer's suggestion may be valuable, but it still needs to fit the product's central test.

Use the stages of software development to think through how a change moves from a validated need into delivery and support. A short record of the assumption, evidence, decision and next action makes the reasoning visible to the team. It also helps prevent an MVP from slowly becoming the full feature set it was meant to avoid.

This week, write a one-page validation plan with the riskiest assumption, the evidence stage you need to reach and the criteria that would make you stop, pivot or invest further. Then book a discovery conversation with Digital Souls Studios LTD to scope the smallest version worth building.

---

Digital Souls Studios LTD supports product teams with specification, design, engineering, infrastructure, launch and ongoing support for web applications, SaaS products and AI automation. If you're ready to test a product proposition without overbuilding it, visit Digital Souls Studios LTD to discuss the smallest useful release and the evidence it needs to produce.