How long does it take to build an MVP, and what to cut?

Ask founders how long their MVP took and you get every answer going. In one Indie Hackers thread, the replies run from three days to four years. That spread isn't because some people are fast and some are slow. It's because "MVP" means something different to each of them.

So here's my honest answer on MVP development: a first version that is genuinely minimum can usually be built in three to six weeks. Most of the ones that take six months weren't minimum. They were a full product with an MVP label on the front.

The worry I hear most is some version of this: it'll drag on for six months, cost double, and nobody will want it. All three tend to come from the same place, and it isn't the code.

Why MVP development drags on

Timelines slip for boring reasons:

• The scope was never written down, so it grows a little every week.
• The product tries to test three ideas at once.
• Every "small" feature turns out to need settings, permissions and an admin screen.
• Nobody on the project is allowed to say no.

There's an old Ask HN thread asking whether you can build an MVP in one week. The replies don't agree on a number, and that's the useful part. Several people point out that an MVP can be a landing page or a demo if all you're testing is whether anyone cares. How long it takes depends entirely on what you're trying to learn.

The lesson isn't "pick the average". It's that the timeline is a decision you make, not a fact you discover.

Fix the timeline, flex the scope

The most useful rule I know: pick the deadline first and let the feature list move. Not the other way round.

If you fix the scope and let the date move, the date always moves. If you fix the date, every new idea has to push something else out. That forces the conversation you should be having anyway: is this more important than what's already in?

In practice:

1. Agree one launch date and treat it as fixed.
2. Write the feature list in priority order, not as a flat list.
3. When something new comes in, it replaces something. It doesn't get added on top.

One hypothesis, one journey

Before any design work, write down the one thing the MVP exists to test. A useful shape is a single sentence naming a specific customer, the specific thing you expect them to do, and why. For example: "Small building firms will upload a drawing and pay for an automated quantity takeoff rather than doing it by hand." One sentence, one bet.

Then design the one journey that tests it. That's the path from arriving to getting the value: sign up, do the thing, see the result. Everything off that path is a candidate for cutting.

If you can't write the sentence, you're not ready to build. That's not a criticism. It's the cheapest possible moment to find out.

What to cut from your first version

This is the list I'd start with:

• Admin panels. For your first users, you can manage data directly in the database or with a no-code tool. I started out in no-code, and this is one place it still earns its keep.
• Multiple user roles. Start with one kind of user. Roles and permissions multiply every screen and every test.
• Native mobile apps. A responsive web app works on phones. App store review, two codebases and update cycles can wait until you know people come back.
• Custom authentication. Use a proven auth provider. Writing your own login system is slower and riskier.
• Premature scaling. You don't need infrastructure for a million users when you have twelve. Caching layers, microservices and multiple regions can all come later.
• Settings and preferences. Pick sensible defaults and see if anyone asks.
• Integrations nobody has asked for yet.

A rough test for everything else: if a feature doesn't help a user complete the core journey, and doesn't help you learn whether the hypothesis is true, it goes on the "after launch" list. That list isn't a graveyard. It's a queue you reorder once real people start using the product and telling you what they actually miss.

What you should never cut

Minimum doesn't mean careless. Four things stay in, whatever the deadline:

• Security basics. Proper authentication and access rules, secrets kept out of the code, HTTPS, and validation on anything a user can type. People trust you with their data from the first sign-up.
• Backups. Automated, and tested at least once by actually restoring one.
• Analytics. If you can't see whether people finish the core journey, you've built the product and skipped the experiment.
• A way to collect feedback. An email address, a short form, a button. Anything that lets early users tell you what's wrong.

None of these are expensive to add at the start. Leaving them out is what gets expensive.

Do AI coding tools make an MVP faster?

Yes, genuinely. The first working version of a screen or an endpoint now takes a fraction of the time it used to. I use these tools every day and I'm not going to pretend otherwise.

What they don't remove is the need to harden the product before real users arrive. A vibe-coded app hosted on Lovable exposed 18,000 users, and the discussion describes access control that was effectively backwards: it blocked logged-in users and let anonymous visitors through. That isn't an exotic bug. It's the kind of basic flaw that someone reviewing the access rules would catch in an afternoon.

So AI tools compress the build. They don't compress the checking. If anything, the checking matters more now, because it's possible to ship code that nobody on the team has read. I've written about what that does to a project a few months later in most AI projects don't fail during the build.

A realistic MVP timeline, week by week

Here's the shape a three to six week build usually takes. Shorter projects squeeze the middle and bigger ones stretch it, but the order stays the same.

Week 1: decide

Write the hypothesis. Map the core journey. Agree the cut list and the launch date. Choose the stack and set up hosting, auth, backups and analytics now, so they're part of the foundation rather than an afterthought.

Weeks 2 and 3: build the core journey

One path, end to end, working with real data. Rough edges are fine. Dead ends are not. By the end of week three, someone should be able to go from sign-up to the result without you guiding them.

Week 4: harden

Test the unhappy paths: bad input, expired sessions, someone pasting another user's link. Review who can see and change what. Check error handling and logging. Restore a backup to prove it works.

Weeks 5 and 6, if needed: polish and launch

Fix what testing found. Put it in front of a small group of real users. Watch where they get stuck, and resist adding anything until you've seen it.

If week three arrives and the core journey still isn't working, that's the signal to cut again, not to extend the date. This is roughly how I run an MVP Sprint.

Is your scope too big? A quick check

• Can you describe the core journey in one sentence?
• Does your MVP have more than one type of user?
• Are you building anything "for later"?
• Is there a feature you'd struggle to explain to your first ten users?
• Would the launch date move if one feature slipped?

If you answered yes to any of the last four, cut first and build second.

Where to start this week

Put the launch date at the top of your scope document. Go through the feature list and move everything that isn't on the core journey below a line. Build what's above the line, launch on the date, and let your first users decide what comes up from below it.

If you'd like a second pair of eyes on what belongs above the line, send me what you're building.