The MVP trap most founders fall into
There are two ways to get an MVP wrong. The first is to build too much: months of features nobody asked for, launched to silence. The second is to build too little: a demo that can’t take payments, leaks data between customers, or falls over when the tenth user signs up.
A good MVP sits between the two. The core workflow is narrow, and the foundations are production-grade: multi-tenant data, proper auth, billing, logging and a way to support users. That combination lets you charge money in week eight and keep building on the same code in month eighteen.
What I’ve built end to end
I’ve taken full products from nothing to production as the only engineer:
- A consumer SaaS with a native desktop app. It includes licensing, Stripe billing, affiliates, Discord integration, an admin console and CI-deployed infrastructure.
- A multi-channel pricing platform. It shipped in seven iterative production releases, driven by weekly feedback from the people using it.
That experience covers both sides of an MVP: getting something real in front of users quickly, and not painting yourself into a corner while doing it.
How the six to eight weeks are spent
- Week 1 is decisions. We settle users, roles, the core loop, pricing model and data model. These are the decisions that are expensive to change later.
- Weeks 2 to 5 build the product. The core workflow comes first, then auth, onboarding and billing. You get a staging link every week.
- Week 6 adds operations. It covers the admin panel, analytics events, error monitoring, transactional emails and backups.
- Weeks 7 and 8 are hardening and launch. That means testing with real users, fixing performance and edge cases, and the production deploy.
Stack choices, explained
My default is Next.js and TypeScript for the product, PostgreSQL for data, Stripe for billing, and Vercel or Railway for hosting. It’s boring, well documented, and easy to hire for later. When the product needs heavy data processing or AI, a Python service sits beside it. Your MVP’s stack should never be the reason you can’t hire your first engineer.
What drives the price
The biggest cost drivers in an MVP are rarely the number of screens:
- Roles and permissions. A single-user tool is simple. Teams, invitations, admin roles and per-record permissions add real work.
- Integrations. Every external system (CRM, accounting, calendars, payment providers beyond Stripe) adds mapping, error handling and testing.
- Billing model. Flat subscriptions are quick. Usage-based billing, seats, trials and proration need careful design.
- Data sensitivity. Health, legal or financial data needs extra security, audit logging and sometimes specific hosting.
During scoping, I show where each feature sits on that cost curve, so you can decide what goes into version one with full information.