Most MVPs take 6 weeks when you stop overbuilding. The 6-month timeline isn't a tech problem - it's a discipline problem.
I've shipped 10+ MVPs. Every single one that took longer than expected had the same root cause: we built things that didn't matter yet. Here's how to stop.
The Real Reason MVPs Take Forever
It's not the tech stack. It's not the team size. It's the constant "but what about..." loop.
Every founder has felt it. You're 80% done, ready to ship. Then you start thinking:
- But what if users want to filter by date too?
- But what if we need analytics on day one?
- But what if someone wants to invite their team?
- But what about edge cases for the upload flow?
Each of these is reasonable in isolation. Stack them together and your 6-week MVP becomes a 6-month project.
Every feature you add before launch is a guess. Every feature you add after launch is a response to data.
The Build vs Skip Framework
Before you write a single line of code for a feature, ask three questions:
1. Will users churn without it?
If a user can't accomplish the core value of your product without this feature, build it. If they can, skip it.
Example: For a todo app, adding tasks is core. Recurring tasks are nice. Don't confuse them.
2. Can you fake it for now?
Most features can be faked or done manually for the first 100 users. Manual onboarding emails. A spreadsheet instead of a database. Stripe payment links instead of a billing dashboard.
Faking it teaches you what users actually do before you spend weeks building infrastructure.
3. Is this a 'someday maybe' or a 'right now' problem?
If you're not sure users want it, skip it. Build it when 5 users ask for it - not when one person mentions it might be cool.
Features You Can Almost Always Skip in v1
These are the features that consistently delay shipping but rarely change whether your product succeeds:
- Admin dashboards - Use the database directly. SQL is faster than building a CRUD UI.
- User profiles - Unless social is core, just store name and email.
- Email preferences - One unsubscribe link is enough. Skip the granular controls.
- Multi-step onboarding - Drop users into the product. Let them learn by doing.
- Settings pages - If you don't have settings, you don't need a settings page.
- Loading skeletons - A simple spinner ships in 5 minutes. Skeletons take hours.
- Animations - Functional beats fancy. Add polish after product-market fit.
- Internationalization - Ship in English. Translate when you have paying users in other languages.
- Dark mode - Pick one theme. Add the other when 100 users ask for it.
- Mobile apps - A responsive web app handles 90% of mobile use cases.
Features You Should Build (Even Though They're Boring)
- Authentication - Use Clerk, Auth0, or Supabase. Don't roll your own.
- Payment - Stripe Checkout. Not a custom billing flow.
- Email - Resend or Postmark for transactional. Don't send from your server.
- Error tracking - Sentry from day one. You will have bugs.
- Basic analytics - Plausible or Posthog. Just enough to know if users come back.
None of these are exciting. All of them save you weeks later.
The Stop-Overthinking Rules
When you catch yourself spending more than 30 minutes deciding on a feature:
- Default to skip. If you're not sure, don't build it. You can always add it later.
- Set a budget. Give yourself 2 hours to make the decision. Past that, ship without it.
- Ask 'what's the worst case?' If the worst case is users ask for it, that's a great problem to have.
- Pretend you have one week left. What would you cut? Cut those things now.
- Show, don't poll. Don't ask users what features they want. Watch what they do without them.
The Real Test
After every feature decision, ask: Did this get a user closer to value, or did it make me feel safer about launching?
Most overbuilding is fear management dressed up as product strategy.
You don't ship when the product is perfect. You ship when removing more features would break the core experience.
The 6-Week Reality
When founders work with me on MVPs, the constraint that makes everything else fall into place is the timeline.
6 weeks forces decisions. It kills 'nice to have.' It exposes 'we don't actually need this.' It pushes you to talk to users instead of building in your head.
The best MVPs I've shipped weren't the most polished. They were the most honest about what users actually needed in week one.
Stop building. Start shipping. Then build what your users actually ask for.