The fastest way to lose $30,000 on a software build is to commission "an MVP" without specifying which definition of MVP you mean. There are three definitions in common use. Founders often have one in mind. Agencies and developers often hear another. By the time the gap surfaces, the project is half-built and the budget is half-spent.
This isn't a vocabulary nitpick. The difference between the three definitions is the difference between a 6-week build and a 6-month build. Between a $10k spend and a $100k spend. Between something that ships and something that drags forever. Knowing which one you're describing before you commission anyone saves real money and real months.
Definition 1: The Reid Hoffman MVP
"If you're not embarrassed by your first version, you launched too late."
— Reid Hoffman, founder of LinkedIn
The Reid Hoffman MVP is a quick, scrappy thing that does one thing for one customer and proves whether the underlying assumption is true. It's not a product. It's an experiment.
What it looks like: a single landing page with a single feature, behind a paywall, hand-glued together with whatever tools work fastest. Often more spreadsheet than software. Often manually-fulfilled (the founder is the "AI" in the early version of the AI tool). Visibly unfinished. Embarrassingly basic.
What it's optimised for: speed of learning. You ship in days or weeks, not months. You learn fast whether the assumption holds. If it does, you build a real product. If it doesn't, you killed the idea before spending real money.
When it's right: when you're testing a fundamentally new idea with no validation, when you have under $5k to spend, when your goal is yes/no learning before commitment.
When it's wrong: when you already have validation and you're trying to ship a real product to paying customers. The Reid Hoffman MVP isn't sturdy enough for that — it's a research instrument, not a business.
Examples: a Bubble app glued to a Stripe payment link. A Notion database with a Tally form on top. A landing page that takes pre-orders for a product that doesn't exist yet.
Definition 2: The agency MVP
The agency MVP is what most agencies build when a founder asks for "an MVP." It's a fully-featured V1 with every common SaaS feature included.
What it looks like: signup + login + password reset + dashboard + main feature + secondary features + admin panel + email notifications + billing + customer portal + mobile responsive + onboarding flow + analytics + GDPR compliance. Everything a "real product" needs.
What it's optimised for: looking professional and being unambiguously launch-ready. Investors can see it. Customers can sign up themselves. The agency can write a case study about it.
When it's right: when you have $80k+ to spend, you've already validated extensively, you're ready for a real launch with real marketing, and the lack of any feature would be visibly unprofessional to your specific buyer (enterprise SaaS for example).
When it's wrong: when you're pre-validation, when your budget is under $50k, when you'd be better served by something smaller that you can change quickly. Most founders who think they want this actually don't — they just don't realise it until the bill arrives.
Examples: any SaaS that ships with a landing page, marketing site, full app, billing, support flows, and a roadmap for V2. Most agency portfolios are full of these.
Definition 3: The founder MVP
The founder MVP is whatever the founder has in mind, which is usually somewhere between Reid Hoffman and the agency, but inconsistently across different conversations.
What it looks like: it changes. In the first conversation with a developer, it's "minimal." In the second conversation, "but obviously we need real auth, not a hacky version." In the third, "and it has to look professional, like a real product." By the fifth conversation, the founder MVP has converged on an agency MVP without anyone noticing.
What it's optimised for: nothing in particular. The founder has competing wants — speed, professionalism, completeness, low cost — and hasn't picked which to prioritise.
When it's "right": never. The founder MVP isn't a real definition; it's an unspecified one. Builds based on it always blow out, because the scope keeps growing as the founder discovers new things they want.
The fix: before commissioning anyone, force yourself to pick definition 1 or definition 2. Then write down which one. Then defend it during the build when scope-creep pressure arrives.
How to know which one you actually need
A diagnostic test:
You need definition 1 (Reid Hoffman) if:
- You haven't sold anything to anyone yet.
- You're testing whether the demand exists.
- Your budget is under $5k.
- You're prepared to throw it away in 3 months.
- Your goal is "answer one question."
You need definition 2 (agency MVP) if:
- You have at least 5 paying-customer commitments in writing.
- You have $40k+ to spend.
- You can sustain a 4-month build before launching.
- Your buyers are sophisticated enough to require professional polish.
- Your goal is "launch a real business."
You need something in between if:
- You have validation but you're bootstrapping.
- Your budget is $10k–$30k.
- You can ship in 8–12 weeks.
- You want a real product but a small one.
- Your goal is "ship the smallest professional product I can defend."
This middle path is what I help most clients build. It's not a Reid Hoffman MVP (it has real auth, real billing, real polish), but it's not an agency MVP either (it has 3–5 features, not 25). I call it a "tight V1" to avoid the MVP word entirely.
The discipline of cutting features
Whichever definition you pick, the hard work is cutting features that survived from your imagination but won't survive your budget. Most founders skip this work and ship over-scoped V1s as a result.
The technique: list every feature you can think of for V1. Ten? Twenty? Thirty? Now apply the test to each:
"If I removed this feature from V1, would the customer who's already promised to pay refuse to pay?"
Cut everything that isn't a yes. The features that survive are the V1. Everything else is V2.
The cuts always include things that feel critical. They're not. The customer doesn't know what's missing because you haven't promised it. They'll discover it after using V1 and tell you what they wanted next, which is far more valuable than your speculation.
A real example from a client: she came to me with a 22-feature list for an "MVP" of a project management tool. After the cut test, four features remained: create projects, add tasks, assign tasks, mark tasks complete. That was V1. Six weeks of build, $9k. Customers used it, told us what they actually wanted, and V2 was a feature set that completely contradicted what we'd have built without their input.
How long should V1 take?
Specific timeline expectations by definition:
| Definition | Build time | Cost | Team | |---|---|---|---| | Reid Hoffman MVP | 1–3 weeks | $0–$5k | Founder + maybe a contractor for one piece | | Tight V1 (the middle) | 6–10 weeks | $8k–$25k | One senior freelancer | | Agency MVP | 12–24 weeks | $40k–$150k | Agency team |
If your "MVP" is going to take longer than the row you've picked, you've over-scoped. Cut features until the timeline matches.
What investors want vs what you need
Common founder error: scoping V1 to impress investors instead of to serve customers. This produces over-engineered products that take too long, cost too much, and ship features investors said they wanted but customers don't use.
The honest reality: investors at the seed and Series A stage will fund a Reid Hoffman MVP if the underlying numbers are good. They don't need to see a polished agency MVP. The deck and the customer numbers matter more than the product polish.
If you're spending $80k of pre-revenue money on agency-MVP polish to "look fundable," you're misallocating. Either build a Reid Hoffman MVP, validate, and raise on the validation — or save the $80k and start with $20k of real product after validation. The middle path of "polish-without-validation" doesn't work for either audience.
The handoff between V1 and V2
A subtle thing most founders miss: V1 should be built knowing that V2 will follow. The architecture choices made in V1 silently determine whether V2 is fast or slow.
Specific examples:
- If V1 uses a single-tenant database design and V2 needs multi-tenancy, the V1 → V2 transition is a 3-month rebuild.
- If V1 hardcodes assumptions about a single customer per account and V2 needs teams, a similar rewrite.
- If V1 stores prices as integers in cents and V2 needs multi-currency, the rewrite is smaller but real.
- If V1 has no concept of "permissions" and V2 needs admin/member/viewer roles, you're rewriting auth.
The fix: when scoping V1, also write down what V2 might look like — even just one paragraph. The developer will make slightly different architectural decisions in V1 to keep the V2 path open, at minimal cost during V1. This single hour of "what does V2 look like?" thinking saves months later.
What to do next
Once you've picked your MVP definition and cut features, the next decisions are validation (have you done enough?) and pricing model (hourly vs fixed). See:
If you'd like to talk about scoping a specific V1, the SaaS Startups and Bootstrappers service pages cover the engagement shapes I most commonly work with.
---
Part of the Full-Stack Development for Solo Founders pillar guide.