The 8-week rule

An MVP should ship in 6–8 weeks. That's enough time to build something real — auth, core feature loop, basic UI, deployed to production. If you're past that and still not live, something is broken.

I've seen teams take 6 months to ship what should have been a 4-week product. The reasons are almost always the same.

Reason 1: Your scope isn't actually minimal

The “M” in MVP is the hardest part. Most founders build a V2 and call it an MVP. They add the nice-to-have settings page, the onboarding flow redesign, the analytics dashboard — features no one has asked for yet.

True MVP scope: one user, one core action, one outcome. Everything else is a feature for v1.1. If your MVP has a notification system, you've already overbuilt it.

The exercise: write down every feature in your current spec. For each one, ask: “If we launched without this, would users be unable to get value?” If the answer is no, cut it.

Reason 2: Too many handoffs

Every time a task crosses a boundary — designer to engineer, frontend to backend, engineer to QA — you lose days. The designer uploads a Figma file. The engineer interprets it. Questions go unanswered for a day. Fixes come back misunderstood.

The math is brutal: a 5-person team with clear specializations has 10+ potential handoff points on any given feature. A solo engineer or a two-person pair with overlapping skills has one or zero.

For early products, the fastest path is a full-stack engineer who can go from concept to deployed feature in one sitting. No handoffs, no async lag, no coordination overhead.

Reason 3: Meetings are your build velocity

Daily standups, sprint planning, backlog grooming, retros, design syncs — each of these feels productive and is functionally anti-productive. A 1-hour meeting for a 4-person team costs 4 engineering hours. That's a feature.

For an MVP: async updates in a shared doc or Slack thread. One weekly sync to unblock things that genuinely can't be resolved async. That's it.

Reason 4: You're rebuilding infrastructure

Every week I see teams spending time on things that should never be custom-built at the MVP stage: auth systems, payment infrastructure, file upload pipelines, email systems.

Firebase Auth, NextAuth, Clerk — all of these give you auth in a day. Stripe gives you payments in a day. Resend gives you transactional email in an hour. Cloudinary gives you image handling in an afternoon.

The rule: if a managed service can do it adequately, use it. You can build custom infrastructure when you have revenue, users, and specific requirements that off-the-shelf can't meet. Not before.

Reason 5: You're optimizing for the wrong things

Perfect code. 100% test coverage. Pixel-perfect UI. These matter. They do not matter at MVP stage. What matters: does the user get value? Does it work reliably enough to demo?

The bar for an MVP is not “production-quality in every dimension.” It's “real enough that real users can tell you if the core idea works.” You can refactor after you have signal.

I shipped ProTeach — a full educational SaaS with 17 games, 4 portals, Stripe billing, and AI tutoring — in 6 days. Not because I cut corners on architecture, but because I made deliberate trade-offs: raw CSS over design systems, simple Firestore queries over optimized indexes, happy-path first then error handling. When the core worked, I hardened it.

What actually moves the needle

If you're stuck, run this diagnostic:

  • Cut 30% of your scope. Not the easy stuff — the core features you think are essential. Force yourself to figure out the actual minimum.
  • Remove one meeting. All of them if possible. Replace with a shared doc of status updates.
  • Ship something broken. Deploy what you have today, even if it's not ready. Real-world testing always reveals different problems than you were solving for.
  • Give one person full ownership. Not ownership of a layer or a component — ownership of the full user experience from end to end. Accountability follows ownership.

The uncomfortable truth

Most slow MVPs aren't slow because the team is bad or lazy. They're slow because there's ambiguity at the top — unclear priorities, undefined success criteria, unstated assumptions about what “done” means.

Fast shipping starts with a founder who knows exactly what they're trying to learn, can say it in one sentence, and is willing to launch something imperfect to learn it.

Everything else is an engineering problem. Engineering problems are solvable.