A first version (MVP) in production in 6 weeks, week by week
What a first version in 3 to 6 weeks looks like from the inside: the written scope, a demo every week, what you do on your side and what gets cut.
6 min read
Most product projects do not fail at the end. They fail in month two, when the specification has grown, the first demo is still "next sprint" and nobody can say what will be live by summer.
You have probably seen the version of this where the quote said four months, the team said six, and the board asked for a date nobody could give.
We aim for a first version in production within 3 to 6 weeks of kick-off. Call it an MVP if you like. We say first version, because it runs in production with real users, not in a demo.
Six weeks is the upper case, for a product with a few integrations and real users on day one. Here is what those weeks look like: what we ship, and what you do.
Before week 1: the scope is written down
Nothing starts before a written scope. It fits on a few pages and answers three questions: what we build, what we do not build, and when it ships.
The second list matters more than the first. "No admin dashboard in the first version, exports go to a spreadsheet" is a sentence that saves two weeks. Writing it down before kick-off means nobody has to argue about it in week four.
The scope also names one person on your side who can decide. Not a committee. Someone who can say yes or no to a screen within a day.
If nobody on your side has that time, six weeks becomes twelve. We would rather tell you during the audit than in week four.
On our side it works the same way: the people in the audit are the people who build it. Nobody joins in week three and asks for the context again.
If you have done a free audit with us, its document is the starting point: the opportunity is already chosen, the data is already located.
Weeks 1 and 2: live with almost nothing in it
The first week goes to the parts nobody sees. Accounts, environments, the deployment pipeline, access to your tools and your data. By the end of it, something is deployed to production, even if it is a login screen and an empty page.
Deploying in week one is what keeps the date. Teams that leave deployment for the end meet the security review, the app store delay or the firewall rule in week six. Then the date moves.
The first demo comes at the end of week two; from then on, every week ends with one. It shows the main flow working on real data, with rough edges. For an AI feature, it is the model answering on your actual documents or tickets, not on a sample we picked.
What you do in these two weeks:
- give access: repositories, cloud accounts, the tools we connect to
- name the users who will test, and warn them
- send the real examples: the messy files, the edge cases, the email that always breaks the process
Weeks 3 to 6: the core, then real users
Weeks 3 and 4: the core flow, demoed every week
Each week ends with a demo of what changed, in the real product, not in slides. You click through it yourself.
The demo is where scope decisions happen. You see a screen, you realise half of it is not needed, and we remove it the same day. You see a flow, you realise a step is missing, and we decide together whether it goes in now or after launch.
When something we planned turns out harder than scoped, you hear it at that demo, with two options: cut it or move the date. You do not hear it in week six.
For AI features, this is also when we measure. How often the answer is right, how often it needs a human, how long it takes and what it costs per call. A number on a test set built from your own cases is worth more than a good impression in a meeting.
What you do in these two weeks:
- come to the demo
- answer questions within a day: a question that waits a week costs a week
- say what to remove
Weeks 5 and 6: a small group of real users
The group named in the scope tests it first, never the whole company.
These weeks are for what users find that we did not: the wording that confuses, the case nobody mentioned, the step people skip. We fix what blocks them and log the rest for the next iteration.
By the end of week six, the first version runs in production, with monitoring in place, and the people who use it know where to report a problem. The next iteration is planned from what they actually did in the product.
What you do in these two weeks:
- brief the test group
- collect their feedback in one place
- decide what goes in the next iteration
The six weeks on one page:
| Week | What we ship | What you do |
|---|---|---|
| Before week 1 | Written scope: what we build, what we do not, the date | Name the person who decides |
| 1-2 | Live in production (empty), first demo on real data | Access, test users, the messy examples |
| 3-4 | The core flow, a demo every week, AI measured on your cases | Attend the demo, answer within a day |
| 5-6 | First version with real users, monitoring | Brief the users, sort their feedback |
What gets cut from an MVP to make it
The calendar holds because things come out of the first version. The same items come out almost every time:
- The admin panel. A spreadsheet export or a direct database view covers the first months.
- Every role and permission. One or two roles at launch; the fine-grained matrix comes when someone needs it.
- The edge cases that happen twice a year. They are handled by hand until the volume says otherwise.
- The second platform. Web first or mobile first, rarely both in the first version.
- Full automation. An AI feature that drafts and lets a person validate ships faster and teaches more than one that acts alone.
Tests, security, data rules and hosting choices never go on that list. Your data stays where you decide: hosted in Europe, in your cloud or on-premise.
When it is three weeks, and when it is longer
Three weeks is realistic for an AI feature added to a product that already exists, or an internal tool with one flow and one integration. The infrastructure is there, the users are known, the scope is narrow.
Six weeks is the case described above: a new product, a few integrations, users outside the team.
Some projects take longer, and we say so before kick-off: a platform with payments, a regulated sector, a legacy system with no API. In those cases the first version in production is a smaller slice, and the scope says which one.
The next question is the budget. It follows the scope, not the calendar. The detail is in what an AI project costs.
Where to start
If you have a product in mind and a date you cannot miss, book a free audit. One hour on your business, then a short document: what is worth building first, what is not, and whether a first version fits in weeks or needs more.
