Skip to content

What a 10-day AI MVP actually includes

A working system on your data, an eval score, and the code, plus the four things we deliberately leave out to make the date real.

[Founder name]3 min read

A 10-day AI MVP is one workflow, running on your real data, with a measured accuracy score and the source code in your repository. It is not a prototype, not a slide deck, and not a demo behind a login we control. The date is real because the scope is fixed on Day 0 and four specific things are deliberately left out.

That last part is what makes the promise credible, so let's start there.

What we leave out on purpose

A fixed date only means something if something else gives. Four things do:

  • Breadth. One workflow. Not a platform, not "AI across the business". If your intake process has three variants, we automate the one that carries the most volume and leave the other two visible and manual.
  • The admin UI. Ten days does not include a bespoke dashboard. Output goes into a system you already run: a queue, a spreadsheet, a ticket, an inbox. That is where the work already happens.
  • Edge cases nobody has seen. We build for the distribution your data actually shows and escalate the rest to a person. A system that handles 88% of cases well and hands over the remaining 12% cleanly beats one that handles 97% badly.
  • Infrastructure you don't need yet. No Kubernetes, no queueing layer, no multi-region anything for a process that runs 400 times a day.

Every one of those is a real trade-off, and every one is on the table on Day 0 rather than discovered on Day 8.

What you get

A running system on your data. Not sample data, not a fixture set. Your documents, your records, your edge cases, with whatever inconsistency they actually contain.

An eval score. A labelled set of real cases, held out from development, with the system's accuracy measured against it and the failures listed by cause. This is the artefact most teams have never had, and it is the one that turns "the demo went well" into something a risk or governance forum can approve.

A defined exception path. Where confidence is low, what happens instead, and who sees it. Written down, and demonstrated on Day 10.

The code. In your repository, under your licence, with a README a new engineer can follow and the eval suite runnable from a single command.

A recommendation. Including, sometimes, "don't scale this". That happens, and we would rather say it on Day 10 than sell you a Phase 2.

The shape of the ten days

Day 0 is a scope call, and it is doing more work than it looks like. We are trying to answer one question: what does "working" mean for this workflow, expressed as something we can measure? If we can't answer it, we don't start, an unmeasurable goal is how ten days becomes ten weeks.

Days 1 to 3 are design and the eval set. The eval set comes first deliberately. Writing down what a correct answer looks like, on 100 to 200 real cases, surfaces disagreements between the people who own the process while they are still cheap to resolve. We have had scope calls where building the eval set was the valuable part, because two teams turned out to be applying different rules to the same documents.

Days 4 to 9 are the build, against that eval set, with the score visible the whole way. You can watch it move.

Day 10 is the handover: the system running, the score, the failure breakdown, the code, and a decision.

What makes a workflow a good candidate

The pattern is consistent. Good candidates are:

  • High volume and repeated: at least weekly, ideally daily.
  • Currently done by a person reading things: documents, emails, tickets, forms.
  • Judged by rules that someone could articulate even if nobody has written them down.
  • Already producing a record we can use to build the eval set from history.

Bad candidates usually fail on that last point. If nothing about the current process is written down anywhere, we cannot measure whether the automation is right, and an AI system you cannot measure is a liability rather than an asset.

The honest caveat

The first increment is not where the compounding value is. It is where you find out whether working with us, on this class of problem, produces something your team will actually use. Plenty of first increments end at Day 10 with a useful system and no follow-on, and that is a perfectly good outcome, you spent ten days rather than two quarters to find out.

Want this built? Start with workflow automation.

We scope one workflow and ship a working, evaluated system in ten days. Fixed scope, fixed timeline, and a clear decision at the end.