MVP vs full build for SaaS owners
MVP is a loose term. Here's the model NZ SMEs actually need: minimum scope, solid foundations, designed to grow with continuous delivery rather than a rebuild.
What an MVP is
MVP stands for Minimum Viable Product. The plain idea behind it: the smallest version of a new product you can put in front of real users to find out whether the thing has legs, before you spend the budget to build the rest of it.
That's the easy part. The hard part is that "MVP" has become a loose term. Ask a couple of people what an MVP is and you'll likely get different answers. Before we can talk about how to build one, we need to talk about which kind you actually mean.
The four common MVP models
There's no single agreed definition. We see four interpretations floating around, and they're each useful in the right context.
1. The Lean Startup MVP. The Silicon Valley original. Eric Ries' framing. Build the cheapest, scrappiest version that tests your riskiest assumption. The code is throwaway. If the experiment says pivot, you bin it and start over. Built for venture-funded startups where the budget exists to validate, pivot, and rebuild. Common in San Francisco. Rare in Rangiora.
2. The vibe-coded MVP. The 2026 update on the older approaches of running the service manually or stitching it together with no-code tools. Instead of working out of spreadsheets or building in Bubble or Webflow, you prompt your way to working code through tools like Cursor, Lovable, or Bolt. Cheap. Fast. Built to validate the idea, seek real interest, and designed to be thrown away. Not the codebase you want to build on.
3. The beta-style MVP. Closer to a full release minus the polish. Ship to a small friendly user group, find the rough edges, refine before public launch. What large product companies often mean when they say MVP. Useful for established teams adding a new product line, less useful for a brand new SaaS with no existing audience.
4. The pragmatic foundation MVP. The bare basic functionality needed to onboard real users, on foundations designed to build quickly on top of, not throw away. This is the model that actually fits the NZ SME market, and it's the one we build at Urban Lightbulb. The rest of this article is about what it looks like.
Why model 4 fits NZ SME reality
The first three models work in the contexts they were built for. They struggle in ours.
NZ SMEs typically don't have venture funding. Most are bootstrapped, meaning the business is self-funded from the owner's savings or existing business revenue rather than outside investors. Budgets are real but finite.
That makes throwaway code an expensive choice, whether it's a Lean Startup build or a vibe-coded prototype. Beta-style MVPs are for established teams shipping to an existing audience, which most early NZ SaaS owners don't have yet.
The pragmatic foundation MVP is built for that situation. Ship the smallest useful version now, on a codebase you can keep building on, inside the budget that exists.
What a pragmatic MVP actually looks like
Three things matter. Get any of them wrong and you've either built the wrong thing or built it on the wrong base.
Minimum scope. One core workflow. One user type. Strip out anything that isn't load-bearing for the first ten users. We build what users actually need to use the product, the user dashboard, the settings pages they have to touch. Heavy backend control panels, fancy reporting, and integrations beyond the essential one all wait. So do the advanced features, those get shaped by feedback from your first real users. The smaller the scope, the faster you ship and the clearer the signal you get back from real use.
Solid foundations. Not throwaway code. Proper architecture, a sensible data model, clean structure, the boring infrastructure (auth, permissions, deployment, monitoring) done right from day one. Foundations are invisible when they work and expensive when they don't. We spend the project setup phase of every build on these so that everything we ship after launch lands in the same codebase rather than starting over each time. Our delivery model is continuous, not big-version-numbered releases.
Forward planning with a wishlist. Before any code is written, we map your wishlist. The features you'd want six months in, a year in, three years out. Not to build them now, to shape the foundations so they can be added later without ripping things up. A pricing engine that handles two tiers today should be designed to handle ten tomorrow.
Get those three right and the MVP stops being a gamble. It becomes the first delivery on a multi-stage build, and every dollar you spend on it stays in the codebase.
The traps to avoid
Two patterns we see in pragmatic MVP work. Both cost more than they look like they will.
The over-scoping trap. You add one more feature, then another. The "M" in MVP quietly gets bigger. Before long you're not shipping an MVP at all, you're shipping a slow full build. The budget that was meant to get you to real users runs out before you have any. Each feature looks reasonable on its own. Stack them up and you're shipping weeks later than you needed to. Those are weeks you could have been talking to first customers, learning what matters, and adapting to what they actually use.
The skip-foundations trap. You scope tight, ship fast, and the codebase takes the hit. Six months in, the next developer is fighting the architecture instead of the actual problem. The data model can't support the features you wanted to add, or customer growth is making the system come to a grinding halt. The cheap MVP turns into an expensive rebuild. Believe me, this happens frequently.
Realistic budget and timeline
A pragmatic MVP for a NZ SaaS owner typically sits in the $30,000 to $50,000 range in our pricing bands. A focused medium build, deliberately scoped, with proper foundations.
Timelines run 10 to 14 weeks. Long enough to do discovery, design and foundations properly. Short enough that you're in front of real users before the market moves under you.
Success metric. Define what success looks like before you start. "Ten users from our target market completing the core workflow and choosing to pay" is a real metric. "It works" is not. It matters because it gives you a clear answer when you have to choose what stays in the build and what gets cut.
What happens after. Plan it. A pragmatic MVP without a forward plan is half a build. Whether your next move is to continue to build out features, broaden the scope, or scale up. The plan should exist before launch, before you target customers, because that's when you'll have the bandwidth to think about it, not when feedback is hitting you. The plan should also account for what ongoing maintenance will cost once you ship.
How we'd advise you
If you have real customers waiting, revenue already committed and a clear product picture, go bigger. Build the full thing properly. You're past the point where an MVP is a useful framing.
Budget is usually the sticking point here, even when the demand is real. Most NZ SaaS owners can't fund the full build upfront, so the realistic move is to phase delivery: ship the version that earns its first revenue, then grow the product out of that revenue. We design our builds for that path.
If you're early, with some signal but no committed buyers, scope a pragmatic MVP. Stay inside your budget. Get the foundations right. Ship something real to real users. Build the next thing on top of the same codebase.
If you're somewhere in the middle (some signal, no committed customers, a clear-ish picture), the right move depends on which of the two halves of the problem is bigger.
If you're not sure where your build sits, that's a good conversation to have before money changes hands. A few questions worth asking any developer before you sign is a useful starting point. And if you're still working out whether to build at all, we've written about custom vs off-the-shelf SaaS too.