Most failed products did not fail because the code was bad. They failed because the team built the wrong thing for too long before showing it to anyone. A minimum viable product exists to shorten that distance. Done well, it replaces months of speculation with a few weeks of evidence. This guide describes how we approach MVPs with clients, from the first conversation to the decision about what comes next.
Start with the riskiest assumption
Every product idea rests on assumptions: that a specific group has a specific problem, that they will change their behaviour, that they will pay, that you can reach them. List them and rank them by how badly the idea fails if they are wrong. The MVP exists to test the top one. If your riskiest assumption is that businesses will upload their price lists, you do not need billing yet; you need an upload flow and ten businesses willing to try it.
Pick one user and one job
Resist the temptation to serve everyone. Describe a single user type, in words a stranger would recognise, and the one job they want done. Write it as a sentence: "A site manager records visitors arriving at a construction site in under ten seconds." Every feature proposal is then tested against that sentence. If it does not help the job, it waits.
Cut ruthlessly, then cut again
Founders usually bring a list of thirty features. Sort them into three buckets and be strict about it.
- Must exist for the job to be done: this is the MVP.
- Makes the job nicer: after you have evidence.
- Looks like a real company: dashboards, settings, themes. Later.
It is acceptable, and often smart, to do parts manually. Approve registrations by hand, generate reports yourself, and send invoices from a spreadsheet. Automating a process before you know it is the right process is how budgets disappear.
Choose boring technology
An MVP is not the place to test a new database. Choose a stack your team knows and that is easy to hire for. A mainstream web framework, a relational database and managed hosting will carry you further than most people expect. If you plan a mobile app, consider whether a responsive web app tests the idea faster. When mobile is essential, a cross-platform framework such as Flutter or React Native lets one team ship to both stores.
Design for change, not for scale
You will learn things that invalidate parts of your design. Keep the architecture simple: one deployable application, clear modules, automated tests around the core logic and a pipeline that deploys in minutes. This is not the same as writing sloppy code. Clean boundaries make changes cheap, and cheap change is the real asset of an MVP.
- One repository, one deployment, one database to begin with.
- Authentication and payments from proven providers, not built from scratch.
- Logging and basic analytics from day one so you can see what users do.
Plan the timeline backwards from a launch date
Set a launch date six to ten weeks away and fit the scope to it, not the other way round. Work in one-week increments with a working demo at the end of each. A typical shape is: week one for discovery and prototypes, weeks two to six for building the core flow, and the final weeks for testing, onboarding the first users and fixing what they hit. If the date is at risk, cut scope; do not extend the date.
Prototype before you build
A clickable prototype built in a design tool costs days and often exposes misunderstandings that would cost weeks in code. Put it in front of five target users and watch them attempt the core task without help. Where they hesitate is where the design is wrong. Our UI/UX design work usually starts here for exactly this reason.
Define success before launch
Decide in advance what result would make you continue, change direction or stop. Good MVP metrics are behavioural: the percentage of new users who complete the core job, how many return in the following week, and whether any will pay or commit. Write the thresholds down. Otherwise every outcome can be rationalised as a win.
- Activation: share of sign-ups completing the core task.
- Retention: share returning within seven days.
- Willingness to pay: letters of intent, pre-orders or paid pilots.
- Qualitative signal: what users said they would miss if it disappeared.
Common mistakes to avoid
- Building for investors, not users: polish matters less than a solved problem.
- Waiting for perfect: every extra month is a month without learning.
- No owner: one person must make scope decisions quickly.
- Confusing feedback with demand: people being polite is not the same as people paying.
An example scope cut
Suppose a founder wants a platform where property owners list homes, agents manage clients, buyers search, and everyone chats and signs documents. That is at least four products. The riskiest assumption is that owners will list with a new platform at all. The MVP, then, is an owner onboarding flow, a simple listing page with photos and a public search results page. Chat, e-signature and agent tooling are deliberately absent. Enquiries arrive by email to the founder, who replies by hand.
That version can be built in a few weeks, put in front of fifty owners and tell the founder whether supply exists. If it does, the next release adds the buyer enquiry flow with evidence behind it. If it does not, the founder has learned that cheaply.
Working with a development partner on an MVP
Choose a partner who challenges scope rather than one who accepts every feature. Ask them to describe what they would remove. Agree weekly demos, a shared backlog and a single decision maker on your side. Insist on tests for the core flow and a deployment pipeline from the first week, because those habits cost little early and a great deal late.
- Fixed-scope, fixed-timeline engagements fit well-defined MVPs.
- Time-and-material with a cap fits uncertain scope.
- Keep source code and cloud accounts in your name from day one.
Signals that it is time to invest further
Several signals suggest the product is ready for the next stage: users complete the core task without help, a meaningful share return unprompted, some are willing to pay or commit, and you can describe who they are and how to reach more of them. When those are present, invest in reliability, security, onboarding and growth. Before they are present, more features rarely help.
What happens after the MVP
The MVP gives you a decision, not a finished product. If the evidence is strong, plan the next release around what users actually did, and invest in the foundations the MVP deliberately skipped: scalability, security hardening, a proper admin area and billing. If the evidence is weak, you have spent a small amount to learn something valuable, and you can change direction early.
We help founders and teams scope and ship first versions through our SaaS product development and custom software services. Bring us the idea and the riskiest assumption, and we will help you design the smallest build that tests it.