Scoping an AI MVP: how to ship something real in six weeks
Most AI projects don't fail at the model — they fail at the scope. How we cut an ambitious AI idea down to a six-week build that proves value with real users.
The AI projects that die rarely die because the model wasn't good enough. They die because the scope was a platform when it should have been a feature — six months of build before the first real user touches it, and by then the assumptions baked in at week one have quietly gone stale.
Six weeks is our deliberate constraint for a first AI release. It is long enough to ship something a real user can rely on, and short enough that you cannot afford to build anything speculative. The constraint is the point: it forces every scoping decision the project needed anyway.
Pick one workflow, not one department
The scoping mistake we see most is horizontal ambition: an assistant for the whole support team, a copilot for all of operations. Six weeks buys you one workflow done properly — one input, one decision or output, one user role who owns it.
Choose the workflow by three tests: it happens often enough that improvement is measurable within the pilot, the cost of a wrong answer is survivable, and one specific person will use it weekly and tell you the truth about it. A narrow tool that one team actually adopts beats a broad one nobody trusts — and it earns you the credibility to expand.
Week zero: secure the data and the baseline
Before any build starts, two things must exist. First, access to the real data — not a sample, not a promise that IT will grant it in week three. Data access is the single most common schedule killer in AI projects, and it is a week-zero item precisely because it is outside the build team's control.
Second, a baseline: what does this workflow cost today in time, money or error rate? Without it, the demo at week six is a vibe. With it, the demo is a comparison — and a comparison is what unlocks the decision to invest further.
Spend the first two weeks proving the risky part
Every AI MVP has exactly one question that decides whether it works: can the model actually do the core task on our data, at acceptable quality? Answer that first, with the ugliest possible harness — a script, real examples, a manual scoring pass. No UI, no auth, no pipeline.
If the answer is yes, everything that follows is engineering, and engineering is schedulable. If the answer is no, you have spent two weeks instead of six months finding out, and you can renegotiate the scope while there is still budget and goodwill to do it.
Design for the wrong answer from day one
An MVP does not get to skip failure handling — a pilot user burned by a confident wrong answer in week one will not come back in week four. What an MVP gets to skip is automation of the risky parts.
The pattern that fits a six-week build: the AI drafts, a human approves. Draft the reply, propose the classification, pre-fill the extraction — and keep a person on the send button. This caps the blast radius, and as a bonus, every human correction becomes labeled data for the next iteration.
- Human review on every consequential output — automation comes later, earned by measured accuracy
- A visible way to say 'this is wrong' that takes one click, not a support ticket
- Confident abstention: below a quality threshold, hand off rather than guess
- Log every input, output and correction from the first day of the pilot
Define week six before you start week one
The end of an MVP is a decision, not a demo. Before the build starts, write down the numbers that will make the call: the quality bar on a curated eval set, the adoption signal from pilot users, the measured delta against the baseline. Agree on them with whoever controls the next phase's budget.
Then honor the answer. If the numbers clear the bar, you scale with evidence. If they don't, you have bought the cheapest possible 'no' — six weeks, one workflow, lessons in hand — and that discipline is what separates teams that compound on AI from teams that accumulate abandoned pilots.