Back to blog
startup-advicedevelopment

Shipping an MVP in 4 Weeks: What to Cut and What to Keep

By Loïs Bibehe··7 min read
Developer coding on a monitor

Four weeks isn't a lot of time. But it's enough to ship a meaningful product if you are ruthless about what makes the cut. The problem most founders face is not a lack of skill or speed. It's an inability to say no to features that feel essential but aren't.

After shipping multiple products on tight timelines, I've developed a framework for making these decisions quickly and confidently. Here is how it works.

The One Metric That Matters

Before you decide what to build, you need to answer one question: what is the single metric that will tell you if this product is working?

Not three metrics. Not a dashboard of KPIs. One number. For a marketplace, it might be completed transactions. For a SaaS tool, it might be daily active users. For a content platform, it might be time spent reading.

Once you have that metric, every feature decision becomes simple: does this feature directly move that metric? If yes, it stays. If not, it goes, no matter how cool or "easy to add" it seems.

The goal of an MVP is not to build a small version of your final product. It is to learn whether your core assumption is true as fast as possible.

Features Founders Always Overestimate

After working on several early-stage products (you can see some of them on my projects page), I've noticed consistent patterns in what founders think they need but actually don't, at least not in the first version.

User Authentication Complexity

You probably don't need OAuth with five providers, password reset flows, two-factor authentication, and role-based access control on day one. A simple email and password login, or even magic links, will get you through the first few hundred users. Do not spend three days on auth when you could spend three hours.

Admin Dashboards

In the first month, you can manage your product from the database directly or with a simple script. Building a full admin panel with charts, filters, and export functionality is a luxury you can't afford in a four-week sprint.

Notification Systems

Email notifications, push notifications, in-app notifications with preferences and frequency controls. That's a week of work that adds zero value if you don't have users yet. Start with manual emails. You can automate later.

Settings Pages

Every hour spent on user preferences is an hour not spent on core functionality. Pick sensible defaults and ship. If users complain about a specific default, that's actually great feedback, and you can add a toggle later.

Features Founders Always Underestimate

On the flip side, there are features that seem small but have an outsized impact on whether your MVP actually works.

Onboarding

If a new user can't understand what your product does and how to use it within 60 seconds, nothing else matters. A clear onboarding flow is not a nice-to-have. It is the difference between a user who stays and one who bounces. Invest real time here.

Error Handling

Nothing destroys trust faster than a cryptic error message or a blank screen. You don't need perfect error handling, but you need enough that users are never confused about what went wrong or what to do next.

Performance

A slow MVP is a dead MVP. Users will forgive missing features. They won't forgive a three-second page load. Make sure your core interactions are fast, even if it means cutting features to get there.

Mobile Responsiveness

Unless your product is strictly a desktop tool, ignoring mobile is a mistake. You don't need a native app, but your web experience needs to be usable on a phone. More than half your early traffic will likely come from mobile.

The Four-Week Sprint Framework

Here's how I structure a four-week MVP sprint:

Week 1: Foundation

  • Set up the project, CI/CD pipeline, and deployment
  • Build the data model and core API
  • Implement basic authentication
  • Get the landing page live with a waitlist or signup form

Week 2: Core Loop

  • Build the single most important user flow end-to-end
  • Focus only on the happy path, no edge cases yet
  • Get this in front of at least three people for feedback

If you want to accelerate this phase with AI tools, AI Code Academy teaches the exact techniques we use to ship faster. The foundational courses are free, and you can go deeper with pro courses and coaching through a membership.

Week 3: Polish and Edge Cases

  • Handle the most common error states
  • Add onboarding, even if it's just a few tooltip-style hints
  • Fix the performance issues that matter most
  • Make it work on mobile

Week 4: Launch Prep

  • Set up analytics to track your one metric
  • Write launch copy and prepare distribution channels
  • Do a final round of testing with fresh eyes
  • Ship it

The Hardest Part: Saying No

The biggest threat to a four-week timeline is not technical difficulty. It's scope creep. Every day, you'll think of a feature that would be "really nice to have" or "only take a few hours." Those hours add up fast.

Keep a "Later" list. Write down every idea you cut and revisit it after launch. You'll be surprised how many of those "essential" features never make it off the list because they turn out not to matter.

The founders who ship on time aren't the ones with the best ideas or the most talent. They are the ones who are most disciplined about cutting scope. Being intentional about what you build is the single most valuable skill in early-stage development.

Your MVP is not your product. It is a question you are asking the market. Make sure the question is clear, and ask it as fast as you can.

Loïs Bibehe

Loïs Bibehe

French developer helping founders build products. Work with us or learn to build it yourself. Your call.