Scoping
Should you build an MVP or the full product?
MVP has drifted from a useful idea into a synonym for 'cheap version', which is how people end up shipping something too thin to learn anything from. The genuine question isn't how much to build — it's what you're trying to find out, and what is the smallest thing that would actually tell you.
Rather just ask someone? Talk to usIn short
Build an MVP when you have a genuine unknown to test and a narrow slice that would answer it. Build the full product when the problem is well understood, when you're selling to businesses that expect completeness, or when a thin version would damage your reputation more than it would teach you.
- Minimum viable, not minimum effort
- The point of an MVP is learning, not cheapness. It should be the smallest build that produces a trustworthy answer to your riskiest assumption — which means it has to be good enough that people use it honestly. A version so limited that nobody engages with it teaches you nothing and costs you the same time.
What actually matters
Start from the question, not the feature list
What's the one thing that, if you're wrong about it, makes this a bad idea? Build the smallest thing that answers that. If you can't name the question, you're not scoping an MVP — you're rationing a budget.
Narrow the audience before you narrow the product
It is usually better to build the whole experience for one customer type than half an experience for everyone. Half-experiences produce ambiguous feedback, which is the most expensive kind.
Business customers are less tolerant of thin
Consumers will try a rough product. Businesses evaluating a tool for their operations mostly won't, and a bad first impression at a company can take a year to reset. In B2B the minimum bar is higher than the word 'minimum' suggests.
AI has changed the arithmetic, not the logic
The first working version now costs a fraction of what it did. That makes MVPs more attractive and also makes it far easier to build the wrong thing quickly. The discipline of deciding what you're testing matters more than it used to, not less.
Security and data are never the MVP
You can cut features. You cannot cut protecting customer data, because the downside isn't a poor review, it's a notifiable breach. Everything else is negotiable.
Plan the second version before you ship the first
An MVP produces a list. Teams that haven't budgeted time and money to act on it end up defending v1 rather than improving it, which wastes the entire exercise.
Which approach fits
Most projects sit somewhere between these, and knowing which way you lean is what matters.
| Criteria | MVP first | Full build |
|---|---|---|
| You have | A genuine unknown to test | A well-understood problem |
| Your buyers | Consumers or early adopters | Businesses expecting completeness |
| Budget | Limited, or staged by results | Committed |
| Typical cost | $15,000 – $40,000 | $40,000 – $120,000+ |
| Main risk | Too thin to learn anything | Building the wrong thing thoroughly |
| Timeline | 6 – 12 weeks | 4 – 9 months |
Where we'd tell you otherwise
Sometimes the right answer is to build nothing yet. A landing page, a waitlist and twenty real conversations will disprove a bad idea faster and more cheaply than any MVP. We'd rather tell you that and keep the relationship than take a project that shouldn't exist.
Want a second opinion?
Tell us what you're weighing up. We'll give you a straight answer, including when the answer is that you don't need us.
Common questions
A prototype simulates the product to test whether people want it — it isn't real. An MVP is real software that customers genuinely use for one core workflow. Prototypes typically cost $2,000 to $8,000; MVPs $15,000 to $40,000.
Six to twelve weeks is the usual healthy range. Beyond about three months it has generally stopped being minimum, and the feedback you were trying to get quickly has been deferred for a quarter.
Often yes, and it can be a genuinely good decision — that's exactly what these tools are for. The point to bring in developers is when real customers and real data arrive, because that's where security, reliability and the awkward edge cases start to matter. It's a large part of what we do.
Not if it was built with that in mind. A well-made MVP is a narrow product, not a disposable one: the same foundations extend. Rebuilds become necessary when the first version cut corners in the data model or security, which is exactly where we advise against cutting.
Also worth a look
- What It Costs to Build an App in Australia (2026)
- Need a Fractional CTO for Your Startup?
- How to Choose a Designer for Your Web App
- Already built something that's stuck? We fix those
Last reviewed . Prices are indicative Australian ranges, not quotes.