< blog />
MVP vs full product: the scope that survives 100 users
By Vinicius Ambrozio, founder of VTA Tecnologia · Published
The phrase minimum viable product has been stretched until it means whatever the person saying it needs it to mean. To a founder it means cheap. To an engineer it means unfinished. To an investor it means proof. The original definition, in Eric Ries's Lean Startup principles, is narrower: the smallest thing you can build that lets you learn what to build next.
That definition is useful because it draws a line. An MVP is scoped to learn. A full product is scoped to be sold to strangers who will never talk to you. This article is about what sits on each side of that line, which shortcuts you can safely take on the MVP side, and which ones you will pay for twice. Written by the VTA team, who build both.
What breaks between user 1 and user 100?
The first ten users are usually people you know. You onboard them by hand, you fix their bugs the same afternoon, and if billing fails you send a payment link on WhatsApp. None of that scales, and none of it needs to yet. The point of those ten users is to find out whether the product finishes a job anyone cares about.
Somewhere between user 30 and user 100, the pattern changes. People sign up whom you have never met. They expect a password reset that works at 2am. They invite a colleague and expect that colleague to see the same data, but not everything. Their card expires and they expect to be told, not cut off. One of them exports their data and expects it to contain only their data.
Every one of those expectations is a feature that an MVP legitimately skipped. The mistake is not skipping them. The mistake is building the MVP in a way that makes adding them later a rewrite. CB Insights' analysis of startup post-mortems puts running out of cash and building something nobody needs at the top of the list of reasons startups die, and both are versions of the same error: spending the budget before learning what to spend it on.
What belongs in the MVP and what waits for the full product?
Here is the line as we draw it on real projects. The middle column is what a first release for a few dozen users needs. The right column is what the same product needs before you can stop being personally involved in every signup.
| Capability | MVP version | Full product version | Upgrade when |
|---|---|---|---|
| Signup and onboarding | Invite-only, or a form you approve by hand | Self-service signup, email verification, workspace creation, invitations | You cannot personally welcome every new user |
| Billing | One plan, Stripe Checkout, or a manual payment link | Trials, upgrades with proration, failed-payment recovery, invoices, taxes | The first card fails and you are not there to notice |
| Permissions | One role: the account owner | Owner, admin, member, viewer, plus your support staff acting on a customer's behalf | The first customer invites a colleague |
| Admin area | A database client and a spreadsheet | A real admin panel with search, impersonation and audit logs | You have to answer a support question you cannot answer from the database |
| Data isolation | A tenant column on every table from day one | Row-level security enforced by the database, per-tenant exports and deletes | Never skip the first; add the second before selling to businesses |
| Monitoring | Error alerts to your inbox | Uptime checks, structured logs, a status page | The first customer notices an outage before you do |
| Performance | Correct queries, indexes on the obvious columns | Caching, background jobs, database tuning against real data | A page takes more than a couple of seconds with real data |
| Mobile | A responsive web app | Native apps only if the product needs the camera, offline mode or push at scale | Users ask for it and you can name the feature that requires native |
Notice that data isolation is the one row where the MVP version is not optional. A tenant identifier on every table costs nothing to add on day one and is the single most expensive thing to retrofit. Our multi-tenant architecture guide explains why.
Which shortcuts are safe and which ones become debt?
Not all corners are equal. Some can be cut and picked up later at roughly the same price. Others compound. Here is how to tell them apart.
Safe to skip in an MVP:
- Self-service onboarding. Approving signups by hand for a month teaches you more about your customers than any analytics dashboard.
- Multiple plans. One price, one plan. You do not know yet what people value, so you cannot price the tiers.
- The admin panel. A database client covers the first months; build the panel once you know which support questions repeat.
- Native mobile apps. A responsive web app reaches everyone from one codebase and can be installed to the home screen.
- Automated dunning. When a card fails on customer 12, you email them. When it fails on customer 300, you need the machinery.
- Fancy design. A component library with sensible defaults is fine. Nobody churned because the empty state lacked an illustration.
Never skip, even in an MVP:
The four things that are cheaper on day one than on day 200
These are the shortcuts that turn into a rewrite. Each one costs a day or two in the first week and weeks or months later.
- A tenant identifier on every table. Without it, isolating one customer's data from another's means touching every query in the product. With it, adding row-level security in Postgres later is a migration, not a rewrite.
- Secrets outside the code. API keys in environment variables from the first commit. A key that has been in the repository history is a key you will have to rotate on a bad day.
- A migration system for the database. Every schema change as a versioned migration, so the production database can be reproduced and rolled back. Changing tables by hand in a database client works exactly until the first time it does not.
- Billing modeled around the payment provider's objects. If you use Stripe, keep its customer and subscription identifiers in your database from the first charge and let webhook events drive the state. Payment logic invented in-house and reconciled by hand is the most common thing we are asked to replace.
How do you know you have outgrown the MVP?
The signals are behavioral, not numeric. There is no user count at which a product becomes full; there is a moment when the shortcuts start costing more than the features would. Watch for these:
- You spend more time on manual onboarding and support than on talking to customers about what to build next.
- A customer asks a question you can only answer by querying the production database.
- A card fails and the customer finds out because the product stopped working, not because you told them.
- Someone asks for a role that is not 'owner', and you have to say no.
- You are afraid to deploy on a Friday because there is no staging environment and no rollback.
- A prospect sends a security questionnaire and you cannot answer the question about data isolation with a straight face.
Two of those at once is the moment to plan the second phase. All six at once is the moment most products come to us already on fire, and the second phase becomes more expensive than it needed to be.
How should the contract handle the second phase?
The best contract shape for a first release is a fixed scope small enough to write down completely: one customer type, one workflow, one plan, and the four day-one foundations above. It ships, it goes in front of users, and you learn something. The Y Combinator guidance on planning an MVP makes the same point from the founder's side: launch something small, then iterate on what real users do.
The second phase should be quoted separately, after the first has been in use for a few weeks. By then you know which of the table's right-hand column your product actually needs, and in what order. A vendor who insists on quoting both phases up front is quoting a product neither of you has seen yet, and the number will be wrong in one direction or the other.
What to put in writing for phase one: what is included, what it costs, the delivery date, what happens to the price if you change your mind, and who owns the repository and the accounts. What to put in writing for phase two: nothing yet, except the agreement that it will be quoted against what you learned.
If you want to see how we structure this, the MVP development page covers the first release and the SaaS development page covers what comes after it. We also wrote about what a SaaS build costs, with public numbers.
The detail on the work itself
Frequently asked questions
What is the difference between an MVP and a full product?
An MVP is scoped to learn: the smallest release that tells you whether the product finishes a job anyone cares about. A full product is scoped to be sold to strangers without your involvement, which means self-service onboarding, real billing, permissions, monitoring and an admin area. The line is about who has to be in the room, not about polish.
How many users should an MVP support?
Enough to learn from, which is usually a few dozen. The number matters less than the behavior: once people you have never met sign up and expect things to work at 2am, the MVP shortcuts start costing more than the features would. Plan the second phase when two or more of the signals in this article show up at once.
Which shortcuts should never be taken in an MVP?
Four: a tenant identifier on every table, secrets outside the code, a versioned migration system for the database, and billing modeled around the payment provider's objects with webhooks driving the state. Each costs a day in the first week and weeks or months if retrofitted.
Should an MVP have native mobile apps?
Rarely. A responsive web app reaches everyone from one codebase and can be installed to the home screen. Build native only when you can name the feature that requires it, such as the camera, offline mode or push notifications at scale, and users have asked for it.
Should I quote the MVP and the full product together?
No. Fix the scope of the first release, ship it, and quote the second phase after the first has been in use for a few weeks. A price for both phases up front is a price for a product neither of you has seen yet.
How long does it take to go from MVP to full product?
It depends on which rows of the scope table your product needs and in what order. Self-service onboarding and real billing are usually the first two and are measured in weeks each. Permissions, an admin area and monitoring follow. Doing all of it at once is possible but rarely wise, because each step changes what the next one should be.
Keep reading
SaaS development cost in 2026: what US startups actually pay →
Public price bands for building a SaaS product, the recurring costs nobody puts in the quote, and the five decisions that move a build from five figures to six.
Multi-tenant SaaS architecture explained for founders →
What multi-tenant means, the three ways to separate customer data, how row-level security works in Postgres, and the decisions that are expensive to reverse.
How much does it cost to build an MVP? Real market ranges →
Real price bands from agency profiles selling to US clients, the six things that move a quote, and where fixed scope stops protecting you.
Want a number for your own project?
Tell us what you are building and you get a written scope, a fixed price and a delivery date within 24 hours.