"A few weeks" is the honest answer for a real MVP site. But that range hides the actual question founders need answered: which weeks, doing what, and what's the thing most likely to turn two weeks into six?

A realistic week-by-week shape

Week 1 — Scope and structure. This is where the site's actual content gets nailed down: what pages exist, what each page needs to say, and what action you want a visitor to take on each one. Skipping this step is the single most common cause of a stalled project — development can't move faster than decisions do.

Week 2 — Build. Pages get built against the agreed structure: layout, copy placement, forms, and any interactive elements (booking, calculators, quote requests). For a straightforward marketing or MVP site, this is usually the bulk of the calendar time.

Week 3 — Polish and launch prep. Performance tuning, mobile testing across real devices, accessibility pass, analytics and search console setup, and a final content review. This is also where Core Web Vitals get locked in — it's far cheaper to build fast from day one than to retrofit speed into a slow site later.

A focused single-purpose landing page can move faster than this. A site with e-commerce, user accounts, or custom backend logic takes longer — those add real engineering time, not just more pages.

The three things that blow past the deadline

1. Copy that isn't ready. Design and development can start before final copy exists, but launch can't. The most common real-world delay isn't code — it's waiting on final text, pricing, or photos from the client.

2. Scope creep after the brief is locked. "Can we also add a booking system" after week 1 is a new feature, not a tweak, even if it sounds small. It's not a problem to add — it's a problem to add without adjusting the timeline and budget to match.

3. Third-party dependencies. A payment processor approval, a domain transfer, a client's existing hosting account — these sit outside the development timeline entirely but routinely become the actual bottleneck. Starting these in parallel on day one, not week three, is what keeps a launch on schedule.

How to actually hit the shorter end of the range

  • Come to the first call with your core pages and their purpose already thought through, even roughly.
  • Have at least draft copy ready, even if it's rough — something to refine beats a blank page to wait on.
  • Start any third-party account setups (payment processor, domain, hosting) in parallel with design, not after.
  • Agree on scope in writing before week 2 starts, so additions become a clear, separate milestone instead of silent delay.
Most "the developer is slow" complaints are actually "we hadn't finished deciding what we wanted" complaints. The timeline is almost always honest about the work that's actually left.

If you're ready to scope a real timeline against your specific launch, that's exactly what the first call is for.