What is an MVP?
MVP
An MVP is the smallest version of a product a team can build and put in front of real users to test whether the underlying idea holds up.
MVP stands for Minimum Viable Product. It's the smallest version of a product that a team can build and release to real users to test one specific assumption, before committing the time and money a full build would require. Frank Robinson coined the term around 2001, and Eric Ries popularized it in his 2011 book The Lean Startup, framing it as a tool for learning rather than a smaller, cheaper version of the final product.
The two words carry equal weight and get misread constantly. "Minimal" means as little scope as possible; it isn't an excuse to cut corners on quality. "Viable" means it has to work end to end for the one thing it's meant to test; a broken or fake version answers no question at all. An MVP that people can't complete a real task with tells you nothing about whether they'd want the finished product.
For an agency or small product team, an MVP is a way to avoid spending three months building a full feature set before finding out whether anyone wanted it. The scope gets set by the question you're trying to answer, not by a feature wishlist.
MVP vs Prototype vs Proof of Concept
These three terms describe different stages of testing an idea, and mixing them up leads teams to build the wrong thing at the wrong time.
| Term | Tests | Used by | Is it live? |
|---|---|---|---|
| Proof of concept | Technical feasibility: can this be built at all | Internal team only | No, throwaway code |
| Prototype | Look, feel, or a workflow | Internal team, sometimes a few test users | Usually not, often a clickable mockup |
| MVP | Whether real people will use it and get value from it | Real, external users | Yes, a working product handling real data |
Finding the One Assumption Worth Testing
Before scoping any feature, name the riskiest belief the whole idea depends on. Most teams assume the risk is technical: can we build this? For most agency and SaaS ideas, the technical part is the easy part. The real risk is behavioral: will anyone change what they do because this exists?
An agency considering a client portal add-on might assume the risk is engineering effort. The actual risk is usually simpler and harder to answer in a spreadsheet: will clients log into a portal at all, instead of continuing to email the account manager like they always have? An MVP built to answer that question needs a login, a status view, and a way to measure whether clients return to it, and nothing else. Every feature that doesn't help answer that one question gets cut, not deferred out of laziness but deferred because it doesn't touch the assumption being tested.
How to Scope an MVP: What Stays, What Waits
Start from the full list of features someone eventually wants, then sort each one against the single assumption you're testing. Only what's needed to test that assumption stays in.
| Feature idea | Needed to test the assumption? | Decision |
|---|---|---|
| Client login and project status view | Yes, this is the core interaction being tested | In scope |
| Invoice payment through the portal | No, tests a different assumption about payment behavior | Cut for v1 |
| Custom branding per client | No, doesn't affect whether clients use the portal | Cut for v1 |
| A way to see whether a client logged in this week | Yes, this is the measurement that proves or disproves the idea | In scope |
MVP in Practice: A Client Portal Example
Harker & Cole, an 8-person branding agency, spent two years fielding the same client request: a place to check project status without emailing the account manager. The obvious build was a full client portal with messaging, file sharing, invoice payment, and a branded login page. Full scope, estimated at 10 weeks of development.
Instead, they scoped an MVP around one assumption: clients will use a portal instead of email if it exists. The MVP shipped in 3 weeks: a public status link per project showing progress, completed milestones, and what's next, no login required. No messaging, no payment, no branding controls.
They measured one number: how many clients opened the link in the first 30 days after a project manager sent it. 34 of 40 active clients opened it at least once; 19 opened it more than three times. That result justified the messaging feature next, since repeat visits suggested people wanted to interact with the page, not glance at it once. Payment through the portal stayed cut. It tested a separate assumption that hadn't been validated yet, and building it first would have spent five weeks on a feature nobody had asked to use this way.
- Full-scope build estimate: 10 weeks. MVP scope: 3 weeks
- One number measured: link opens in the first 30 days per client
- 34 of 40 clients opened it at least once; 19 returned more than 3 times
- Messaging got added next because repeat visits showed demand for interaction, not status checking alone
- Payment through the portal stayed cut, since it tested a different, unvalidated assumption
How Long an MVP Should Take to Build
There's no fixed number, but scope creep is the most common reason an MVP timeline balloons past its purpose. A build that takes as long as the full product isn't an MVP anymore, it's the product shipped without proper testing.
| MVP type | Typical timeline | Team size |
|---|---|---|
| Internal tool for one workflow | 2 to 4 weeks | 1 to 2 people |
| Single-feature add-on to an existing product | 3 to 6 weeks | 2 to 3 people |
| Standalone external product, first paying customers | 6 to 12 weeks | 3 to 5 people |
What to Measure After an MVP Launches
The metric has to map directly to the assumption being tested, not to general activity. Watching the wrong number gives a false sense of confidence in either direction.
- Activation rate: the percentage of people who complete the core action the MVP was built around, rather than sign up alone
- Return usage in the first 2 to 4 weeks, which separates curiosity from a real behavior change
- Direct qualitative feedback, collected by talking to the first 10 to 20 users rather than reading a survey summary
- A willingness-to-pay signal where relevant: would they pay for this today, in this exact form
Scoping MVPs in Melororium
Teams scope an MVP as a project in Melororium with a fixed budget and a deadline, using the Canvas tab to document the one assumption being tested so it stays visible to everyone working on it, not buried in a chat thread from three weeks ago.
Tasks tagged as "MVP scope" versus "post-MVP" keep the cut list visible on the same board instead of in a separate spreadsheet, and Project Health flags budget burn against the original scope in real time so a quietly expanding MVP gets caught before it eats the whole timeline.
Available in every plan starting at $29/mo for 4 users.
In Melororium
Scope and track your MVP in Melororium
Common mistakes with mvp
What teams get wrong most often, and what to do instead.
- 1
Confusing minimal with low quality
Shipping something broken and calling it an MVP. The product has to work end to end for the one thing being tested; cutting scope is not the same as cutting whether the thing functions.
- 2
Testing more than one assumption at a time
Bundling a pricing test, a positioning test, and a product-market-fit test into one launch. When the result comes back mixed, there's no way to tell which assumption failed.
- 3
No predefined success criteria before launch
Shipping without agreeing in advance what result would confirm or kill the idea. Afterward, any number can get argued into meaning whatever the team wants it to mean.
- 4
Building for a need nobody confirmed
Writing the scope from an internal guess about what users want, without talking to the people the MVP is meant to serve first. The build answers a question nobody asked.
Frequently asked questions
Is an MVP the same as a beta version?
No. A beta is usually a near-complete product released to a limited audience for final testing before a full launch. An MVP is a deliberately incomplete product built to test whether the core idea is worth pursuing at all.
How much should an MVP cost?
It depends entirely on the assumption being tested, not on a fixed budget. A useful check: if the MVP costs close to what the full product would cost, the scope wasn't minimal.
Can an MVP be internal, not customer-facing?
Yes. A team testing whether a new internal workflow saves time can build an MVP for their own staff before ever showing it to a client. The same scoping rules apply: test one assumption, measure one result.
What comes after the MVP?
If the assumption holds, the team adds the features that were deliberately cut, prioritized by what the MVP's usage data showed people wanted next. If it doesn't hold, the team changes direction before sinking more budget into the original idea.
Does Melororium help teams build MVPs?
Melororium tracks an MVP as a project with a budget, deadline, and a Canvas document for the core assumption being tested, so scope decisions stay visible to the whole team instead of living in someone's notes.
