A properly scoped MVP — one core workflow, done well — is typically a matter of weeks to a few months, and the range is driven almost entirely by scope rather than by who builds it. Anyone giving you a confident number before seeing your feature list is guessing, including me.

What's more useful than a number is understanding where the time actually goes, because that's what you can influence. This is part of the founder's guide to building an MVP.

Where the weeks go

A build has five phases, and founders consistently misjudge how the time is distributed between them.

The surprise for most founders is hardening. The demo-able version of a feature arrives quickly; the version that survives real users takes roughly as long again. Empty states, failed payments, someone losing connection mid-upload, a form submitted twice — none of that is visible in a demo and all of it is visible on day one of real usage.

When a project feels "nearly done" for three weeks, this is why. It genuinely is nearly done in the sense the founder means, and genuinely isn't in the sense that matters.

The three things that blow timelines

1. Scope changes mid-build

By far the biggest. Every "while you're in there, could we also…" has a cost, and when nobody prices it, it gets paid in schedule instead.

The fix isn't refusing to change anything — requirements genuinely do evolve. The fix is a change process: every addition gets estimated, and you decide explicitly whether to add time, remove something else, or drop it. Ten minutes of process, and it converts an invisible schedule leak into a visible decision.

Getting the exclusion list written down during scoping is what makes this conversation easy rather than adversarial.

2. You being unavailable

This one is entirely within your control and founders reliably underestimate it.

A developer blocked on a decision for four days has lost four days you paid for. It doesn't matter that they were "waiting on you" — the calendar moved. Multiply that across a project and unavailability is often the single largest source of delay.

Practical version: agree a response commitment in both directions. If you can answer questions within 24 hours during the build, you will materially shorten it.

3. Unknowns in third-party systems

Integrations are where estimates go wrong honestly. A payment provider without a proper sandbox, an API with undocumented behaviour, a client's existing system that turns out not to work the way anyone said — these are real and they're hard to price in advance.

The mitigation is sequencing: do the risky integration first, not last. If something is going to be a problem, you want to find out in week two when you can still change the plan, not in the final week when the launch date is public.

Ask candidates which part of your project they consider riskiest and when they plan to tackle it. "The unknown thing, early" is the answer you want. It's also a good vetting signal.

The phase founders try to skip

Discovery. Every time.

It feels like paying someone to talk. It's actually the phase with the highest return in the project, because every feature removed there is time and money not spent on it later, and every ambiguity resolved there is a mid-build stall that doesn't happen.

Projects that skip discovery don't save the discovery time. They spend it later, in worse conditions — as rework, as stalls, as the conversation in week six where it turns out you and the developer meant different things by "user account."

What a realistic schedule looks like

Ask for milestones tied to things you can see, not to percentages:

• Wireframes for the full workflow
• The main flow working end-to-end on a staging URL, rough but real
• The same flow hardened, on mobile, with error handling
• Analytics, monitoring, and deploy in place
• Launch

Each milestone should be small enough that if it slips badly, you find out in days rather than at the end. That's the actual purpose of milestones — early detection, not accounting.

When it slips

It will, at least a little. What matters is how it's communicated.

Fine: "The payment integration is taking longer than I estimated because their sandbox doesn't support refunds. I need another week, or we can ship without refunds and add them after launch."

Specific cause, specific impact, a choice offered.

Not fine: silence, then "nearly there" for three consecutive weeks.

The pattern to watch for is a developer who reports the same percentage complete repeatedly. That usually means they're stuck on something and haven't said so. A direct, non-accusatory question — "what's the thing you're most worried about right now?" — often surfaces it faster than asking for a status update, because it gives permission to name a problem.

How to actually shorten it

In order of effectiveness:

1. Cut scope. Nothing else comes close. Removing one non-essential feature saves more than any process improvement.
2. Fake things manually. Onboarding by phone, matching by hand, reports in a spreadsheet. Real to the user, near-zero build cost.
3. Be responsive. Answer within a day.
4. Freeze the scope during the build. Keep a list for v1.1 instead.
5. Do the risky part first.

What doesn't work: adding developers to a late project, or asking for the same scope in less time. The second one just moves the cost to hardening, and hardening is where the bugs your users will find get fixed.

If you want a realistic read on whether your scope fits your deadline before you commit, get in touch.