How to Build an MVP: Scope, Delivery, and Evidence

How to build an MVP without funding the entire product

To build an MVP, identify a consequential uncertainty, define one complete workflow for a specific audience, and deliver the smallest version that can generate evidence through real use. Before development begins, decide how you will observe behavior, which safeguards are essential, and what findings should guide the next investment.

The objective is not to release something small at any cost. It is to obtain useful learning without committing prematurely to a full product.

This guide starts after you have identified a real problem. The decisions now concern execution: what must work, what can wait, and whether to use existing tools, build software, hire a partner, or operate part of the service manually.

What an MVP must demonstrate

MVP stands for minimum viable product. In The Lean Startup, Eric Ries connects the concept to validated learning about customers with the least necessary effort. That does not make every unfinished product a useful MVP.

An MVP must provide an experience realistic enough to investigate a business hypothesis. A prototype can explore comprehension or navigation. A proof of concept can investigate technical feasibility. Neither alone establishes that people will adopt and continue using a service.

Validation is also not a single, permanent status. Usage does not establish willingness to pay. A purchase does not establish retention. Retention in a heavily assisted pilot does not prove that the operation is economically sustainable.

Replace “validate the product” with a narrower question: which assumption must we investigate to make the next investment decision?

A completely fictional example

Imagine a cooperative that rents modular exhibition kits. Its coordinators need to track incomplete returns, currently recorded in scattered notes. The proposed software would use a subscription model priced per operating location.

The initial hypothesis is that recording an issue and assigning an owner helps coordinators follow it through to resolution. The MVP lets someone open a return record, identify missing components, assign responsibility, and close the issue.

It does not include a commercial catalog, freight estimates, route planning, or automated billing. Those capabilities might belong in a future product, but they are unnecessary for investigating this workflow.

This scenario was invented solely to explain scope decisions. It is not a Soulsy customer case, a real conversation, or an observed outcome.

A six-step MVP planning framework

1. Choose the risk worth investigating next

List uncertainties about adoption, operations, technology, and revenue. Ask which incorrect assumption would make the proposed development investment largely unhelpful.

In the fictional example, storing return records might be straightforward. The larger uncertainty could be whether coordinators will record an issue during a busy shift. Improving infrastructure before observing that behavior would address the wrong question.

Write the hypothesis with an audience, situation, and observable behavior. “Coordinators will record incomplete returns without researcher intervention” is more testable than “the interface will be intuitive.”

2. Define a complete workflow, not a collection of screens

A usable slice starts with a trigger and ends with an outcome. Include the initial input, the central action, feedback to the user, and handling for foreseeable failures.

For the imaginary cooperative, the trigger is an incomplete kit arriving back. The outcome is an issue with a known owner and status. The workflow must accommodate missing information and corrections to an assignment.

This prevents a common scope problem: several polished screens that still do not let anyone finish a meaningful task.

3. Separate essentials, exclusions, and safeguards

Your MVP scope needs three explicit lists:

• Essential: capabilities required to complete the workflow and investigate the hypothesis.
• Deferred: capabilities that do not change the immediate decision.
• Required safeguards: proportionate protections such as access control, recovery, and appropriate data handling.

“Minimum” does not justify exposing information or making mistakes irreversible. Where legal duties or specialized controls apply, investigate them before a live pilot.

Document manual work too. If someone creates accounts, corrects records, or processes requests behind the scenes, that labor belongs in the operating model and cost estimate.

4. Choose the delivery method around the uncertainty

Use a manually assisted service when the main uncertainty concerns customer value and the service can be delivered safely that way. Consider existing software or no-code tools when they can support the workflow, permissions, and data export requirements.

Custom development becomes more compelling when an essential integration, rule, or interaction cannot be investigated adequately with available alternatives.

A hybrid is possible: a simple interface, manual processing, and one limited integration. Just do not mistake an automated-looking experience for proof that the underlying operation can scale.

5. Prepare observation before release

Define events tied to outcomes: task started, task completed, abandonment, help requested, and return usage when another relevant need arises.

Combine usage records with conversations about specific episodes. Ask what happened during the last attempt rather than only asking whether someone likes the idea.

Record who was invited, what assistance they received, and the conditions of use. A closely supported pilot can conceal difficulties that would emerge during independent use.

Only collect the data needed for the evaluation, with appropriate access and retention practices. Instrumentation should not become a reason to gather unnecessary personal information.

6. Agree on continue, revise, and stop criteria

Before testing, document what would justify further investment and what would require a change. Criteria should reflect the task frequency, operating context, and consequences of failure.

The fictional cooperative might require independent task completion and repeat use when another incomplete return occurs. Those would be proposed experiment criteria, not industry benchmarks.

If the observation window provides no second opportunity to use the product, evidence about recurrence remains inconclusive. A lack of evidence should not become automatic approval to expand.

Build internally, use no-code, or hire a partner?

The choice depends on available capability, constraints, and the cost of changing direction—not just the speed of the first release.

An internal team can preserve continuity and keep learning within the organization. It still needs actual capacity across product, design, engineering, and operations. Technical capacity without prioritization ownership can produce activity without direction.

Existing software or no-code can support workflow testing without developing every component. Check permission limits, integrations, usage-based costs, and export options. A working demonstration does not settle those questions.

A specialist partner may help when delivery requires skills or coordination you do not have available. The agreement should define responsibilities and outcomes, not simply a screen count.

When comparing proposals, request:

• The hypothesis and workflow the delivery will let you investigate.
• Explicit exclusions and external dependencies.
• Acceptance criteria and failure handling.
• Instrumentation and pilot support.
• Ownership, access, and export arrangements for code and data.
• Maintenance, handover, and change terms.

A low quote may shift substantial work onto your team. A larger quote may include unnecessary functionality. Compare the total cost of obtaining the evidence that matters.

Estimate time and cost without false precision

There is no universal MVP price. Workflow complexity, integrations, data sensitivity, operating requirements, and team availability all affect the estimate.

Separate the budget into definition, implementation, infrastructure, pilot operations, evaluation, and handover. Include the time spent on manual delivery rather than treating it as free.

Ask for estimates with assumptions and unresolved questions. If an integration has not been investigated, keep it visible as an open dependency. A fixed deadline that ignores uncertainty does not remove it.

Where uncertainty is concentrated, consider a limited technical investigation before committing to the larger implementation. Its purpose should be to answer a specific feasibility question, not quietly expand the product scope.

Common mistakes that weaken the evidence

Treating registration as delivered value. Creating an account is not the same as solving the problem. Observe completion of the relevant task.

Automating an operation you do not yet understand. You may harden rules that still need to change. Conversely, do not hide the cost of manual assistance when assessing viability.

Adding a feature for every objection. A complaint may signal unclear instructions, the wrong audience, or a need outside the chosen scope. Investigate before expanding.

Confusing enthusiasm with commercial commitment. Praise and stated intent do not substitute for a buying decision. If revenue is the hypothesis, include an actual offer with clear commercial terms.

Ignoring people who leave. Speaking only with active participants gives an incomplete account of adoption barriers.

An action plan before approving development

Create a short decision document:

1. Describe the audience and usage situation.
2. Select the highest-priority hypothesis.
3. Map the end-to-end workflow.
4. List scope, exclusions, and safeguards.
5. Compare feasible delivery methods.
6. Define observation, owners, and decision criteria.
7. Estimate the full cost of the pilot.

Review it with the people funding, building, and operating the product. Resolving disagreement at this stage avoids embedding conflicting expectations in an advanced implementation.

Sources and the limits of this guidance

The Lean Startup by Eric Ries supports the connection between MVPs and validated learning. It does not establish a universal project budget, delivery timeline, or conversion threshold.

The 2020 Scrum Guide, by Ken Schwaber and Jeff Sutherland, supports the importance of usable increments and a shared Definition of Done. It does not define an MVP or require you to use Scrum.

The framework here is a practical planning synthesis. The cited sources do not demonstrate a quantified success rate for these particular steps.

FAQ

Does an MVP need custom code?

No. It can combine existing tools and manual work if that arrangement lets you investigate the hypothesis under relevant conditions. Custom code is justified when an essential capability requires it.

How many features should an MVP have?

There is no standard number. Include what is needed to finish a workflow, observe the outcome, and operate with appropriate safeguards. A seemingly small feature can carry extensive dependencies.

Can you validate an MVP with a small audience?

A small pilot can reveal task-level problems and patterns worth investigating. It does not automatically support market-wide conclusions. Document the findings, participant characteristics, and assumptions that remain unresolved.

When should you expand the MVP scope?

Expand when evidence from the current workflow justifies the next hypothesis or identifies an essential blocker. Make the reason explicit rather than accommodating every suggestion.

Conclusion

Building an MVP means defining a real experience and using its results to make a better investment decision. The scope should be small enough to change and complete enough to teach you something consequential.

If you need to organize these choices before commissioning or developing software, the Soulsy diagnostic is a possible next step for a focused conversation about scope, risks, and evidence.