The most expensive software is software nobody uses. Many new products fail not because they were built badly, but because they were built on assumptions nobody tested: that customers have the problem, that they will pay to solve it, or that the technology will behave as expected at scale. Prototypes and a minimum viable product (MVP) exist to test those assumptions cheaply, before you commit your full budget.
Yet “MVP” has become one of the most misused terms in software. For some it means a rough demo; for others it means version one with half the features removed. In this article we untangle the terminology, show how to identify the assumptions that really matter, describe validation techniques that cost less than writing code, and explain how to scope and measure an MVP so it produces decisions rather than just a launch date.
This is also the thinking behind the Prototyping Phase in our own development process, where we confirm that a plan can actually be executed before full development begins.
Why validating before building matters
Every product idea rests on a stack of assumptions. Some are low risk: users will want to log in, invoices will need a PDF export. Others are existential: small retailers will switch from spreadsheets to your app, or the supplier’s API can deliver stock levels in real time. If an existential assumption is wrong, it does not matter how well the rest of the system is engineered.
Validation is about learning which assumptions hold, in the right order, at the lowest cost. A sketch that reveals a confusing workflow costs an afternoon. Discovering the same problem after six months of development costs a redesign, a delayed launch and frequently a difficult conversation with investors or the board. For founders and corporate innovation teams alike, the discipline of validating first protects both budget and credibility.
Prototype, proof of concept or minimum viable product?
These terms describe different tools for different questions. Using the right one prevents both over-building and under-building.
| Prototype | Proof of concept | Minimum viable product | |
|---|---|---|---|
| Question it answers | Do users understand and want this? | Can this be built technically? | Will real users adopt it and, ideally, pay? |
| Audience | Target users, stakeholders | Internal technical team | Real customers in the market |
| Form | Sketches, wireframes, clickable mock-ups | Minimal code exercising the risky component | Working, deployed software with a small feature set |
| Code quality | Often none, or throwaway | Throwaway | Production quality: secure, tested, maintainable |
| Typical effort | Days | Days to a few weeks | Weeks to a few months |
| Output | Usability and desirability insight | Technical feasibility answer | Usage data, feedback and revenue signals |
The effort column is illustrative only; actual timelines depend on scope and complexity. The key point is that each step increases cost, so you should only move to the next step once the previous one has answered its question.
Start with your riskiest assumptions
Before choosing a technique, write your assumptions down and rank them. A useful framework groups them into four types of risk:
Desirability
Do people actually have this problem, and is it painful enough that they will change their behaviour? Evidence comes from talking to potential users about their current workflow, not from asking whether they “like the idea”. People are polite; their past behaviour is more honest than their predictions.
Viability
Can the product sustain a business? Will customers pay enough, and can you reach them affordably? For internal enterprise tools, viability means the time or cost saved justifies the build and the ongoing maintenance.
Feasibility
Can it be built with the available technology, budget and integrations? Risky dependencies include third-party APIs, legacy systems, offline requirements, payment flows and anything involving machine learning on real-world data.
Usability
Can users figure out how to get value from it without hand-holding? A product that solves the right problem but confuses its users will still fail.
Plot each assumption by how important it is and how little evidence you have. The assumptions that are both critical and unproven are where your first experiments should focus.
Validation techniques that cost less than code
Many important questions can be answered before a developer writes a line of production code. These techniques are listed roughly from cheapest to most involved:
- Problem interviews. Speak to people in your target market about how they handle the problem today, what it costs them and what they have already tried. Look for patterns, not compliments.
- Landing page tests. Describe the product, its benefits and, ideally, its price, then measure how many visitors sign up or request access. If you collect names or email addresses, remember that the Protection of Personal Information Act applies: state why you are collecting the information and use it only for that purpose.
- Clickable prototypes. Design tools let you create realistic, tappable mock-ups of a mobile or web app. Put them in front of five or so representative users per round, give them a task and watch where they hesitate. Usability problems show up quickly.
- Concierge tests. Deliver the service manually to a handful of customers. If you plan to automate supplier quotes, compile them by hand first. You learn exactly what customers value before automating it.
- Wizard of Oz tests. Present an interface that looks automated while people perform the work behind the scenes. It is ideal for testing whether users want an “AI-powered” feature before investing in models.
- Pre-sales and letters of intent. For business-to-business products, a signed pilot agreement or deposit is stronger evidence than any survey.
- Technical spikes. Time-boxed proofs of concept that answer a feasibility question, such as whether a legacy system’s data can be extracted reliably.
Scoping a minimum viable product that is genuinely minimal
Once the key desirability and feasibility questions have encouraging answers, it is time to build something real. The hardest part of an MVP is not building it but deciding what to leave out.
Focus on one user and one core job
Identify the primary user and the single most important outcome they need. Every feature in the MVP should directly support that journey. Everything else goes on a “later” list, which is not a rejection, only a sequencing decision.
Use a prioritisation method
Techniques such as MoSCoW (must have, should have, could have, won’t have this time) make trade-offs explicit and give stakeholders a shared language for saying “not yet”. Be strict with the “must have” category: if the product can deliver its core value without a feature, it is not a must.
Reduce platform and integration scope
Launch on one channel first where possible. A responsive web app may test demand before you invest in native apps, and a cross-platform framework such as Flutter lets a single codebase serve both iOS and Android when mobile is essential. Replace complex integrations with simple imports or manual processes until volume justifies automation. Our article on what drives the cost of a mobile app shows how these choices affect budget.
Do not cut the foundations
“Minimum” applies to features, not to quality. If the MVP succeeds, its code becomes the base of your product. Sound architecture, automated tests for business logic, secure authentication, proper handling of personal information and a reliable deployment pipeline should all be in place. Cutting these corners creates technical debt at exactly the moment you need to move quickly.
How our Prototyping Phase de-risks the build
Our six-phase process places prototyping deliberately between architecture and full development. After the Conceptual Phase has selected technologies to suit your budget and scale, and the Structuring Phase has produced a maintainable, scalable system design, the Prototyping Phase applies those chosen structures and technologies in practice. The aim is to discover potential issues early and confirm that the plan can actually be executed.
In practice that may mean validating an integration with a payment gateway or an existing ERP, confirming that a chosen framework handles an offline-first requirement, or putting key screens in front of users to confirm the workflow. Only when those questions are answered do we move into the Development Phase, where development and testing run together for each sub-task. You can read more about each stage on our How We Work page.
Executing a vision with precision starts with understanding it fully. Prototyping is where assumptions meet reality, while changes are still cheap.
Measuring an MVP: metrics and decision points
An MVP launch is the start of an experiment, not the end of a project. To learn from it, decide before launch what you will measure and what result would change your plans.
- Activation: what proportion of new users reach the moment where they first experience the core value, such as creating their first invoice or completing their first booking?
- Retention: do users come back in the following weeks without prompting? Retention is usually the clearest signal of genuine value.
- Conversion: if the product is paid, do trial users become paying customers?
- Qualitative feedback: short interviews with both active and lapsed users explain the numbers.
- Operational signals: support requests, errors and performance problems reveal where the experience breaks down.
Instrument the product with privacy-respecting analytics from day one, and schedule a review at a fixed point after launch. At that review, choose consciously: persevere and build the next most valuable features, pivot on a specific assumption that proved wrong, or stop and redirect investment. Each is a legitimate outcome of a well-run MVP.
Common MVP mistakes to avoid
- Building for everyone. Trying to serve several user types dilutes the core experience and the feedback.
- Treating the MVP as a lower-quality version one. Users judge the product they see; a buggy, insecure release teaches you nothing useful.
- Launching without success criteria. Without a target agreed in advance, any result can be rationalised as success.
- Waiting for perfection. Every additional pre-launch feature delays the learning the MVP is meant to produce.
- Ignoring disappointing data. The purpose of validation is to find out where you are wrong. Act on it.
How Adriel Corp can help
We help founders and organisations turn ideas into validated products, from mapping assumptions and prototyping key workflows to building a production-quality MVP that can grow. If you are still shaping the idea, our Discovery & Architecture Workshop is a focused starting point. If you are ready to put a mobile product in users’ hands, our Mobile App MVP Package offers a structured route to building and launching a carefully scoped first release.
Tell us about the idea you want to test, and we will help you find the quickest responsible route to real evidence.
