The hardest sentence to say to a founder is "no, you don't need that yet." But it's the sentence that gets them shipped. Every MVP I've seen ship has been at least 30% smaller than the one the founder originally described. The ones that didn't get cut down before the build are the ones that didn't ship at all.
Here's how to do the cutting yourself, before any developer quotes you anything.
What an MVP is actually for
An MVP exists to test one specific hypothesis: that some users will pay (or do the equivalent commitment) for some version of your product. Nothing more.
An MVP is not:
- A small version of your full product.
- The first 80% of your roadmap.
- A polished early-access tier.
It's a hypothesis test. The smaller it is, the faster the test runs. The faster the test runs, the more iteration you get for the same money.
The cut-list framework
Take your full feature list. Run every line through these questions in order. The first "no" cuts the feature.
- Does the hypothesis depend on this? If the experiment can run without it, cut.
- Will the first 20 users notice it's missing? If not, cut.
- Can we manually do this for the first 50 users? If yes, cut. (Manual = you do it on your phone, in a spreadsheet, with a Calendly link.)
- Is this a "later" feature or a "must" feature? If anyone says "later," cut.
- Would we ship without this in three weeks if we had to? If yes, you're already cutting it; just commit.
In my experience, this cuts about 40–60% of the original list. The remaining list is your real MVP.
The features founders fight hardest to keep
Predictable, every time:
- Onboarding flows. Build a sign-up form. Email people. Skip the wizard.
- Admin dashboards. Use the database directly for the first 20 customers. Build admin in version two.
- Email notifications. Send them by hand for the first month. You'll learn what users actually need notified.
- Multi-tenancy. Add it when you have your fifth paying customer. Not before.
- SSO and SAML. Email + password is fine for 99% of MVPs. The enterprise customer asking for SSO will wait.
- Mobile app companion to the web app. Build the responsive web first. The native app is a $30k decision; defer it.
Every feature you ship in the MVP is a feature you have to support, market, and explain. Cut now. Add when signal demands.
The "wizard of oz" trick
The most underused tool in MVP design is the manual backend. Examples:
- "Match users with experts in 24 hours", the user fills a form, you review submissions in your inbox, you reply by hand. Build automation in version two.
- "Generate a personalised report", the user fills a form, you write the report yourself, you email it as a PDF. Build the generator when you have 30 customers.
- "Real-time chat", start with email. Move to Intercom when volume justifies it.
Manual backends are slower per transaction but they're effectively free to build. They also teach you what the automated version actually needs to do, by giving you 50 examples of real user behaviour before you write a line of code.
Two-week sprints, hard stops
Inside the build, the same principle applies. Pick a two-week sprint. Whatever's on the list at the end of two weeks is what ships. Anything not done is cut or punted to next sprint.
This is how disciplined teams ship in eight weeks instead of six months. The features cut from each sprint feel painful at the time and almost always feel right in retrospect.
What "MVP done" actually looks like
A real MVP usually has 30–40% of the original feature list. It looks slightly embarrassing. There are sharp edges, it doesn't do things you assumed it would. That's correct. If your MVP doesn't make you slightly uncomfortable, it's too big.
The bottom line
The MVP mistake is building too much. The cut-list above gets your scope to 30–40% of the original. Ship that. Iterate based on real users.
If you want three Australian developers who push back on scope as a feature, FindDevs is exactly that. Free, three quotes, 24 hours.