Three to six weeks for a focused first version built by a small senior team working in weekly increments; six to fourteen if it needs accounts, payments, two platforms and an admin surface. The range is wide because engineering is rarely the constraint — decision speed on the client side usually is.
The honest answer is three to six weeks for a focused first version, and six to fourteen if it needs accounts, payments, two platforms and somewhere for your own team to administer it.
But the number is the least useful part of the answer, because in practice the schedule rarely breaks on engineering. It breaks on decisions. So here is what those weeks actually contain, and where they actually go wrong.
What the weeks contain
| Week | What happens | What we need from you |
|---|---|---|
| 0 | Discovery call, scope written down, fixed quote issued | An honest description of the problem, not a spec |
| 1 | Architecture, data model, the skeleton app running on a staging URL | Credentials and third-party access. This is the week it matters. |
| 2–4 | The core loop built in weekly increments — the thing the product exists to do | Fifteen minutes a week to look at a working demo and react |
| 5 | Edge cases, error states, the unglamorous half nobody demos | Real content, real test data |
| 6 | Launch: deployment, store submission if mobile, handover of accounts and repository | Your own accounts, in your own name |
Notice that you appear in every row. That is deliberate, and it is the whole reason schedules slip.
Where the time actually goes wrong
Decisions, not code
The single most common cause of a late project is a question that sits unanswered for four days. Should unverified users see the dashboard? What happens when a payment fails on a shared account? These are business decisions wearing technical clothing, and no engineer can make them for you. A project with one empowered decision-maker moves roughly twice as fast as the same project run by a committee — not because committees are foolish, but because a committee's calendar is the critical path.
The undocumented third party
Every integration you do not control is a scheduling risk, and the risk is proportional to how badly it is documented. A modern API with a sandbox costs a day. A legacy system with no documentation is a discovery project, and the correct way to handle it is to scope it separately rather than bury it in a fixed line item and hope. We have taken one of those apart; the honest version is to timebox the unknown before committing to the estimate around it.
Scope added quietly
Not the big obvious additions — those get discussed. It is the small ones: "could it also send an email there?" Each is genuinely small. Ten of them is a week. The fix is not rigidity, it is bookkeeping: every addition is an explicit trade against something already in scope, decided in the open.
Waiting on content
The build finishes and launch waits three weeks for copy, logos, legal text and a privacy policy. Utterly avoidable, and extremely common. Start it in week one.
What an MVP should not include
The fastest way to blow a six-week schedule is to build things nobody asked for. In rough order of how often we see them:
- An admin panel, before anyone knows what needs administering. A database view and a few queries carry you a surprisingly long way.
- A settings screen, for a product with no users to have preferences.
- An onboarding flow, for a product nobody is onboarding to yet.
- The second platform, before the first has told you whether the idea works.
- Scale engineering, for load that does not exist. It is cheaper to rebuild a bottleneck you actually hit than to pre-empt five you never will.
The test for every feature: name the user who will use it in the first month. If you cannot, it is not in the MVP.
Why "weekly demo" is a schedule mechanism, not a courtesy
A working demo every week is not a status report. It is the mechanism that keeps the estimate honest. Discovering in week two that the core loop feels wrong costs a day to change. Discovering it at handover costs the project. Any engagement where the first thing you see is at the end is a project whose risk has been quietly transferred to you.
That cadence is also what makes fixed pricing workable at all — a subject with its own economics.
Book a free 30-minute discovery call. You'll get an honest read on what is genuinely a six-week build and what is not — and a fixed quote within 48 hours with the scope written down.
Book a free discovery call