What a 4-Week AI MVP Includes, Week by Week
A week-by-week look at what gets decided, built and handed over in a fixed 4-week sprint, and what we leave out on purpose.
Key takeaways
- A 4-week AI MVP is planned around one problem that, once solved, makes the product worth using on day one.
- Week 1 ends with a clickable prototype tested with real users; weeks 2 and 3 build the core workflow on real data with a staging demo every week.
- Week 4 is production deployment and handover of source code, documentation and admin access, and the code belongs to you from the first commit.
- Features left out are written down and sized, then prioritised after launch using real usage.
A 4-week AI MVP includes one clearly defined problem, a clickable prototype tested with real users in week 1, a working core workflow built on your real data in weeks 2 and 3, and a production deployment with full handover in week 4. It does not include every feature on the original wish list. Those are written down, sized and planned for after launch.
Most founders and operations leads come to us with a long feature list. A fixed 4-week sprint forces a different question: which single problem, if solved, would make the product worth using on day one? Everything in the sprint is planned around that answer. The rest of this post walks through what happens each week, what you receive at the end, and what we leave out on purpose.
Why the sprint is fixed at four weeks
A fixed length changes how decisions get made. When the end date cannot move, the conversation shifts from “what else could we add?” to “what must be true for this to be useful?” That shift is the main reason the format works.
It also makes cost and risk easier to reason about. You know when the product will be live, and you know what you will hold at the end: running software, the source code, and the documentation to keep it running. If the product turns out to be the wrong idea, you have learnt that in four weeks rather than six months.
Throughout the sprint you talk directly to the technical lead who is building the product. There is no account manager passing messages along, so questions get answered by the person who knows the code.
Week 1: listen, understand, prototype
The first days are interviews with the people who will use the product, and a close look at the data it will run on. We want to see the current process as it actually happens, including the spreadsheets, the WhatsApp groups and the workarounds.
By the end of the week there is a clickable prototype that the team can put in front of real users. It is not a slide deck. People tap through it on their own phones or laptops and tell us where it does not match how they work.
What week 1 produces:
- A problem statement agreed in one sentence
- A short list of who uses the product and what each person needs to do in it
- Data sources identified, with read access confirmed
- A clickable prototype reviewed with real users
- A written list of what is in scope and what is deferred
The data part matters most for AI work. If the model needs three years of order history and that history sits in four different exports with different column names, we need to know on day two, not day twelve. Our checklist for getting your data ready before an AI project covers the questions we ask.
What a good problem statement looks like
A useful problem statement names the user, the task and the outcome. “Drivers can complete deliveries and capture proof of delivery even when they lose signal” is specific enough to build against. “Improve logistics with AI” is not.
On a driver app for a Singapore logistics company, the one-sentence problem was about working offline at the Causeway, where connectivity is unreliable. That single constraint shaped almost every technical decision that followed.
Weeks 2 and 3: core build on real data
We build the core workflow and the integrations it depends on, using your real data from the start. Sample data hides problems. Real data shows the missing fields, the inconsistent product codes and the edge cases that matter to your team.
Every week ends with a demo on a staging link. You and your team use the product yourselves, not just watch a screen share. Feedback arrives while it is still cheap to act on.
If a feature does not serve the one problem we agreed on in week 1, it goes on the list for after launch.
What gets built in this phase
- The main user flow, end to end, on the devices people already use
- The AI component, whether that is classification, extraction, generation or search, connected to real inputs
- The integrations the core flow cannot work without
- Basic roles and permissions so the right people see the right data
- Logging, so we can see what the AI is doing and where it is unsure
How AI quality is checked
An AI feature is only as useful as its worst common answer. During weeks 2 and 3 we agree with someone on your team who can judge whether an output is right. They review a set of real examples each week. Where the model is unsure, the product shows that clearly or hands the task to a person, rather than guessing.
On an omnichannel retail project in Jakarta, AI writes product tags and descriptions in Bahasa Indonesia and English. For work like that, the right reviewer is whoever knows what a correct product description looks like, not whoever is most senior.
Week 4: production and handover
The product is deployed to production. Real users start using it. We stay close during the first days to fix anything that real usage reveals.
At handover you receive:
| Item | What it means for you |
|---|---|
| Source code | In your repository, with full history. Ownership is yours from the first commit. |
| Documentation | How to run, deploy and change the product, written for the next developer. |
| Admin access | Credentials for hosting, databases and third-party services, under your accounts. |
| Backlog | The deferred features, each with a rough size and the reason it was deferred. |
Nothing is held back. If you want to continue with another team, or hire your own developers, they can start from the documentation and the code without needing us.
What we leave out on purpose
Four weeks is enough for one problem done properly. It is not enough for everything at once. These are the items we usually defer:
- Admin features nobody will use in the first month
- Integrations that can run as a CSV export for now
- Edge cases that affect fewer than one in a hundred users
- Reports that nobody has yet asked a specific question of
- Settings screens for options that can be configured by us for now
None of these are forgotten. They are written down, sized and planned for the weeks after launch, once real usage tells us which ones matter. Often the item that seemed urgent in week 1 turns out to be rarely needed, and something nobody mentioned becomes the top request.
A quick test for scope
When a new request comes up mid-sprint, we ask three questions:
- Does it serve the one problem agreed in week 1?
- Will the product be unusable on day one without it?
- Is there a manual or CSV workaround for the first month?
If the answers are no, no and yes, it goes on the backlog.
How to prepare for a 4-week sprint
You do not need a specification document. You do need a few things in place:
- One decision-maker who can make scope calls quickly
- Two or three people who will actually use the product and can spare time for interviews and demos
- Read access to the data, or a named person who can grant it
- A clear picture of what “working” looks like on day one
If you have these, the first week is spent building rather than waiting. It also helps to know that we aim for a minimum lovable product rather than a bare MVP: fewer screens, each one finished properly.
If you have a problem in mind and want to check whether it fits a 4-week sprint, tell the technical lead what you have in mind. We will tell you plainly if it does not.
Frequently asked questions
Can a useful AI product really be built in four weeks?
Yes, if the scope is one problem and the data is reachable in week 1. Four weeks is not enough for a long feature list, which is why the first week is spent agreeing what the product must do on day one.
Who owns the code at the end of the sprint?
You do. The source code lives in your repository from the first commit, and at handover you also receive the documentation and admin access to every service the product runs on.
What happens to features that do not fit in the four weeks?
They go on a written backlog with a rough size for each item. After launch, real usage shows which ones matter, and those are planned as follow-on work.
What do you need from us before week 1?
A decision-maker who can join a short call each week, access to the people who will use the product, and read access to the data it will run on. Our data checklist covers the details.