How long does it take to build an MVP? Week by week
How long an MVP takes, told week by week: what ships in each watch, what slows a build down, and how to plan a first release you can actually hit.
Entered
3 min read
A scoped MVP takes a small number of weeks, not months, when one team designs and builds it and the first release is cut to a single core journey. We plan every build in watches: one watch is one week, and every watch ends with a working build at a preview link and a log entry you can read.
The honest answer to "how long" is "as long as the scope". So here is what each week looks like, and what stretches it.
Before week one: call and proposal
- The call. Thirty minutes, free, with the people who would do the work.
- The proposal. Within three working days of the call you get a written brief, a watch-by-watch plan and a fixed price.
Nothing is designed or built yet. This is where the timeline is really decided, because this is where scope is decided.
Week one: scope
We open your log. The brief is confirmed, the core user journey is agreed in one line, and your repository and preview URL are set up in your organisation. For a Starter Build, the core flow is also drawn and reviewed this week.
Week two onward: design and build in weekly watches
Every week runs the same way:
- Monday: set the course. We agree what this week will ship, in one line you can hold us to.
- Wednesday: review. Design reviews the build in progress. Anything off course is flagged the same day.
- Friday: enter the log. A working build at a preview link, and a log entry for every project by 17:00 UTC+1.
A typical MVP opening looks like this on the log:
| Watch | Course | Remarks |
|---|---|---|
| Wk 01 | Scope | Core user journey agreed. Repo set up in your org. |
| Wk 02 | Build | First deploy to your preview link. |
| Wk 03 | Review | Design reviews build one. |
A Starter Build is shorter: its prototype is live at a preview link in week two.
The last week: ship
Launch, a handover document, and every decision already on record. After that, optional monthly care: fixes and small features, still logged.
What actually makes an MVP late
Build speed is rarely the problem. These are:
- Scope that grows quietly. Each "small" addition is a day. Ten of them is two weeks. We log every change with its cost and time before we start it, so growth is visible and chosen.
- Waiting on decisions. A build stalls when a question sits unanswered. Our log marks these with a flag, and every flag becomes the first line of that Friday's email.
- Waiting on access. API keys, app store accounts, payment provider approval. Start these in week one, not the week they are needed.
- Integrations you don't control. Third-party sandboxes break and approvals take days. Plan buffer for them, not for your own screens.
How to get a date you can hit
- Cut the first release to one journey a user must complete.
- Decide web first or native first in the proposal, not in week three.
- Name one person on your side who can answer questions within a day.
If you want a watch-by-watch plan for your product, book a scoping call. The plan comes with a fixed price, in writing.
Next step