Your MVP is probably not minimal enough
The biggest mistake founders make is treating MVP as "version 1.0 of the full product." It's not. An MVP is the smallest thing you can build to test whether your core assumption is wrong.
Instagram's MVP was a photo app with one filter. Dropbox's MVP was a video. Zappos's MVP was a guy buying shoes from a store and mailing them to you.
If your MVP has user roles, admin dashboards, and notification preferences, it's not an MVP. It's a product with no users.
The 8-week MVP framework
We've built MVPs for over a dozen startups. The ones that succeed follow a pattern.
Week 1-2: Define what you're testing. Write one sentence: "We believe [target user] will [take action] because [reason]." Everything in your MVP exists to test this sentence. Everything else is a distraction.
Week 3-4: Design the critical path. Design only the screens a user touches to complete the core action. Not settings. Not onboarding. Not error states (yet). If your core action is "book a consultation," you need: discover providers, view a provider, book a time, confirm. Four screens.
Week 5-8: Build and ship. Use whatever technology ships fastest. For most B2C apps, React Native gives you iOS and Android from one codebase. For B2B, a web app is fine. Don't build your own auth system. Don't build your own payment system. Use Clerk, Firebase Auth, Stripe. These are solved problems.
Week 9-12: Measure and decide. Put the MVP in front of 50-100 real users. Not friends, not investors, not your mom. Real target users. Watch them use it. The data will tell you whether to iterate, pivot, or stop.
What your MVP doesn't need
A scalable backend. If your MVP needs to handle 100,000 concurrent users, you don't have an MVP problem, you have a scaling problem. And you don't have that problem yet. Use a simple database. Optimize later.
Perfect code. Your MVP code will probably be thrown away. That's fine. The purpose is learning, not engineering excellence.
All platforms. Pick one. iOS or Android, not both. Web or mobile, not both. You can't learn twice as fast by being on two platforms.
What your MVP does need
Real payment integration. If your business model involves money (and it should), charge from day one. Willingness to pay is the strongest signal of product-market fit. A user who says "I'd totally pay for this" is lying. A user who enters their credit card number is not.
Analytics. If you can't measure behavior, you can't learn. Implement event tracking for every meaningful action. Mixpanel, Amplitude, or even simple custom events to Firestore.
A feedback mechanism. In-app feedback button, short post-action surveys, or direct contact with users. Make it absurdly easy for users to tell you what's broken.
Common MVP mistakes
Building before talking to users. If you haven't had 20 conversations with target users before writing code, you're guessing. Guessing is expensive.
Confusing an MVP with a prototype. A prototype demonstrates a concept. An MVP tests a business hypothesis. Prototypes are for investors. MVPs are for customers.
Spending 3 months choosing a tech stack. The stack doesn't matter at MVP stage. What matters is shipping speed and your team's familiarity with the tools.
Frequently asked questions
How much should an MVP cost? $40K-80K for a focused MVP with one core workflow. If someone quotes you $200K for an MVP, they're building a full product.
Should we build in-house or outsource? If you don't have a technical co-founder, outsource the initial build. An experienced team ships an MVP in 8 weeks; a first-time founder hiring engineers takes 8 weeks just to start.
What happens after the MVP? Three outcomes: iterate (the hypothesis is partially validated, refine the product), pivot (the hypothesis is wrong but you learned something valuable), or scale (clear product-market fit, invest in engineering quality and growth).
Need help shipping an MVP fast? We build focused MVPs in 8-12 weeks.