Most MVPs fail not because the idea was wrong, but because they never launched.
I've built 10+ products from scratch. Some for clients, some for myself. And I've watched the same pattern repeat across almost all of them: a founder with a real problem to solve, a reasonable budget, a clear deadline — and then, gradually, a feature list that grows until the deadline becomes a suggestion and the budget is gone before the product is live.
The features that cause this are almost never obviously wrong. They're features that sound necessary. That a reasonable person would think belongs in a product. That will probably be in the product eventually. The problem is adding them before you have a single real user.
Here are the five I see kill MVPs most consistently.
1. Complex Role and Permissions Systems
Almost every SaaS founder I work with has, somewhere in their mental model, a permissions matrix. Admin, user, manager, viewer, editor, guest. Different access levels for different parts of the product. Org-level permissions that cascade down to resource-level permissions.
I understand why. It feels like building for the future. It feels responsible.
It's almost always premature.
In every product I've shipped, the initial live version needed exactly two roles: admin and user. The admin can do everything. The user can do the subset of things they need to do. That's it. The "manager" role that seemed essential in planning? Either nobody used it, or the requirements for it changed so significantly once real users showed up that the original implementation was rebuilt anyway.
The cost of complex role systems isn't just development time. It's the cognitive overhead every subsequent feature has to carry. When you add a new feature, you now have to think about which roles can access it, whether the permission check goes at the route level or the component level or both, whether the permission state needs to live in the session or be fetched per-request. That overhead compounds. Every feature takes longer to build than it should.
Start with admin and user. You can always add granularity; you can't un-ship complexity.
The one exception worth acknowledging: if your core value proposition is multi-user collaboration with meaningful permission differences between user types — something like a document editing tool where the distinction between editor and commenter is the product — then yes, you need this at launch. But "we might have enterprise clients someday who need fine-grained access control" is not that exception.
2. Full Notification Systems
Picture the notification settings page you're imagining: email, SMS, push notifications, in-app, a preferences page with toggles for every event type, a digest option, frequency controls. It's tidy. Users will appreciate having control.
You don't know yet what users want to be notified about.
This sounds obvious when stated directly, but it's not obvious when you're building. You have a mental model of how users will use your product, which events matter to them, which will feel intrusive versus helpful. That mental model is wrong in specific ways you cannot predict before you have real users interacting with real data.
When I built pikkuna.fi — the e-commerce platform with a full order automation pipeline — I started with email only. One channel. Order confirmation, shipping update, invoice. After real usage, I had data about which notifications users actually looked at, which ones generated support tickets ("I didn't know my order shipped"), which ones were ignored. That data drove every subsequent notification decision.
If I had built the full preferences matrix upfront, I would have been building controls for events I didn't know mattered and missing notifications for events I hadn't anticipated.
Pick one channel. Ship notifications for the two or three events that are obviously important. Then let actual usage tell you what's missing.
3. Custom Admin Dashboards with Analytics
Founders want to see everything before launch. Total users, active users, revenue, churn, feature usage, funnel metrics, conversion by cohort. They want a dashboard.
This is the feature I push back on most directly.
You don't need a custom analytics dashboard when you have 5 users. You need it when you have enough users that manual database queries become time-consuming, and when you understand enough about what matters in your product to know what to measure.
Both of those conditions take time to develop. Building a custom dashboard before them means building something based on assumptions about what will matter — assumptions that will mostly be wrong.
The tools that actually serve you here already exist. PostHog is free up to 1 million events per month and covers funnel analysis, session recordings, feature flags, and A/B testing. For revenue metrics, Stripe's own dashboard is genuinely good. For questions that require your specific data model, a direct database query takes 30 seconds to write and gives you exactly the answer you need.
The one thing worth building early: a simple internal view of any operational data you'll actively manage. Not analytics — operations. In vatnode.dev, the only "admin view" at launch was a table showing API key usage so I could see if any key was hitting rate limits unexpectedly. That took two hours. Everything else was Stripe and PostHog.
4. Multi-Tenancy and Team Features
slug="mvp-development"
text="Building an MVP and trying to draw the line between what's essential and what's premature? That's exactly the kind of call I help founders make."
/>
You're building for individual users first. But you're thinking: eventually businesses will want to use this. Teams will need shared workspaces. Multiple users under one account. Invite flows. Billing per seat.
The instinct to design for this upfront is understandable. It feels more scalable. It feels like you're avoiding a future rebuild.
You're not avoiding a rebuild. You're doing it now, before you need it, for users who don't exist yet.
Multi-tenancy changes the data model at a fundamental level. Your concept of "ownership" for every record in the database changes. Your billing model changes. Your auth logic changes. Your permission model — which, per point one, you've hopefully kept simple — changes. Every query that was "get this user's data" becomes "get this team's data, scoped to this user's access level within this team."
I've done this migration on real products. It's not impossible. It's also not as bad as building it speculatively before you understand how teams will actually use the product.
The right time to add multi-tenancy is when a real, paying user tells you they need it, or better, when several of them do. At that point you have real requirements, real usage patterns, and the revenue to justify the engineering work.
5. Onboarding Flows and Feature Tours
You want new users to succeed. So you invest in onboarding: a welcome modal, a step-by-step feature tour, tooltips on every interactive element, an empty state that explains what to do first, a progress checklist. Thoughtful, genuinely well-intentioned work.
Here's the problem: you don't know yet where users get confused.
Onboarding is a response to a problem you don't fully understand yet. Users get confused at specific moments for specific reasons — reasons that depend on what they expected, what they already know, what they were trying to do when they got stuck. You can guess at these. You will be partially right. But the best onboarding comes from watching real users fail at real tasks and building targeted guidance for those specific failure modes.
For every product I've shipped, the post-launch reality of where users got stuck was different from my pre-launch assumptions. Different features, different moments, different misconceptions. On vatnode.dev, I assumed friction would concentrate around EU VAT rule complexity — which numbers are valid, which countries require additional checks. The actual drop-off was at API key setup: developers expected an OAuth flow and didn't find the simpler token in the dashboard. A single sentence in the empty state fixed it. If I had built a full onboarding flow based on my pre-launch assumptions, I would have spent days explaining VAT edge cases that nobody reached.
What to build instead: a simple empty state that tells the user the one thing they should do first. Ship that. Do five customer interviews in the first two weeks. Watch where users hesitate or abandon. Build onboarding around what you learn.
What You Actually Need in an MVP
I've told you what to cut. Here's the short version of what to keep:
Authentication. Users need to be able to sign in and have their data be theirs. Better Auth handles this in a day: email/password, optional magic links or OAuth, session management. Don't roll your own.
The core loop. Whatever the primary action of your product is, it needs to work reliably. Not beautifully — reliably. This is the thing worth spending the most time on and getting right before launch.
A way to collect payments. If you're charging money, which you should be even in early access, Stripe Checkout takes half a day to integrate. There's no reason to delay this.
Basic error handling and monitoring. Not a custom monitoring dashboard — Sentry on a free tier takes an hour to set up and will catch the errors that actually matter before users report them.
One notification for the most important event. An email that confirms the user's key action. That's it.
The full production checklist I work from — auth, billing, database, API, monitoring — is documented in the SaaS production checklist article. But for an MVP, the question isn't "what does a production SaaS need?" It's "what does a user need to complete the core loop and pay you for it?" If you need to make these scope decisions with a technical partner rather than alone, that's exactly what MVP development looks like in practice.
Everything else is something you build after you have users.
Why This Keeps Happening
Most of the over-building I see isn't driven by bad judgment. It's driven by a specific anxiety: the fear that something will be missing when users arrive, and that users will leave because of it.
This is a real risk. It's also much smaller than the risk of never launching.
The products that fail from scope creep don't fail because users arrived and left immediately. They fail because users never arrived at all — the launch kept slipping, the feature list kept growing, the budget ran out, the founders burned out, and eventually the thing that was supposed to be a product became a half-finished codebase that nobody shipped.
Ship the core. See what users actually want. Build that.
When I built HTPBE? — the PDF forensics SaaS — the first working version analyzed documents with a basic 5-layer check, returned a result, and let you pay for it. No preferences. No admin dashboard. No team features. No elaborate onboarding. It was live in days. Seven iterations of the algorithm later, I understood what actually mattered because I had real usage to look at.
That's the pattern. Get something in front of users fast. Let reality tell you what to build next.
The job of an MVP is not to look complete. It's to expose the right uncertainty as fast as possible.
items={[
{
q: "What features should an MVP actually include?",
a: "The minimum set that lets a real user complete the core loop and pay you for it. That means: working authentication (Better Auth handles this in a day), the primary action of your product, Stripe Checkout for payments, basic error monitoring (Sentry free tier), and one email confirming the user's key action. Everything else — roles, dashboards, notifications, onboarding tours — comes after you have users telling you what they need.",
},
{
q: "Why is multi-tenancy a mistake in an MVP?",
a: "Multi-tenancy changes the data model at a fundamental level: ownership of every record changes, billing logic changes, auth scoping changes, and every query changes. Building it before you have real team-based customers means doing the migration twice — once now, once after you understand how teams actually use your product. The right time to add multi-tenancy is when a paying user explicitly asks for it.",
},
{
q: "Do I need a custom analytics dashboard for my MVP?",
a: "No. You need analytics when you have enough users that manual database queries become time-consuming and you understand what to measure. At early-stage, PostHog covers funnel analysis and session recordings on a free tier, Stripe's dashboard handles revenue metrics, and a direct SQL query answers anything specific to your data model. A custom dashboard built on pre-launch assumptions will measure the wrong things.",
},
{
q: "How do I know when scope creep is happening?",
a: "The clearest signal: features are being added to the roadmap because they sound necessary rather than because a real user asked for them. A role system 'for enterprise clients we might have someday', notifications for every conceivable event type, an onboarding tour that explains features before anyone has found them confusing. If no real user has expressed the need, the feature is probably premature.",
},
{
q: "What is the real cost of building premature features?",
a: "The direct cost is development time. The compounding cost is that every subsequent feature has to carry the weight of earlier decisions. A complex role system means every new feature needs permission logic. A full notification framework means every new event needs a preferences toggle. The product slows down as it grows. The most common outcome of scope creep is not a bad launch — it is no launch at all.",
},
]}
/>
If you're building an MVP and trying to draw the line between what's essential and what's premature — that's exactly the kind of problem I work on. I've shipped 10+ products and learned most of this the hard way so the founders I work with don't have to.
If you need someone who can own the technical scope end-to-end and help you make those calls — get in touch. I'm available for freelance projects and longer-term engagements. And if you're already past MVP and the question is scale — the vatnode.dev SaaS shows what a production-ready architecture looks like from day one.
Top comments (0)