What an MVP Sprint Gets Right About AI Products

The hardest thing about building AI products is not the model. I learned that early, and every project since has confirmed it. An MVP Sprint on an AI product is a different kind of sprint from a CRUD app. The model is one component. The workflow around it, the verification logic, the approval gates, the fallback paths, that is the actual product. Get the workflow wrong and the model's accuracy is irrelevant.

The model is not the product

When I built Fursa, a visa route eligibility tool, the temptation was to treat the language model as the answer machine. Ask it a question, return the result, ship it. That would have been a mistake. Visa eligibility is a legal domain. A wrong answer does not just frustrate a user. It can send someone to the wrong consulate, cost them money, or worse. So the model became a classifier inside a larger verification pipeline. Its output was checked against structured source data before anything reached the user. The model accelerated reasoning. It did not replace it.

This is the pattern I return to consistently. The model does the heavy lifting on ambiguous, unstructured input. Deterministic logic handles the parts where correctness is binary. The two have to be composed deliberately, not wired together with hope.

Verification is not optional, it is architecture

In 2025 and into 2026, production AI architecture moved away from single-prompt RAG toward multi-agent workflows. Frameworks like LangGraph and CrewAI became standard for managing stateful, iterative tasks. The reason is not that single-prompt RAG is bad. It is that production requirements, auditability, recovery from partial failure, human approval on high-stakes steps, cannot be met by a single call to a model.

On OptimalTax, an automated tax return system for the public sector, we hit 99% tax calculation accuracy. That number did not come from a better model. It came from a pipeline that validated intermediate outputs before passing them downstream, and from explicit human approval gates on edge cases the model flagged as uncertain. The model knew what it did not know. That required engineering, not prompting.

If you are building an AI product and your architecture diagram is just a box labelled "LLM" with arrows in and out, you are describing a demo, not a product.

What an MVP Sprint actually scopes

A standard MVP Sprint for an AI product covers eight to twelve weeks. In that window, I have to make decisions that will be expensive to undo: which steps in the workflow need deterministic validation, where human approval is required before the system proceeds, how the product behaves when a model call fails or returns low-confidence output.

Those are not polish decisions. They are structural. And they have to be made early, because the cost of retrofitting verification logic into a pipeline that was built without it is high. I have seen teams spend more time unpicking a naive pipeline than they spent building it.

The scoping work is also where I push back on scope. An AI product that tries to do everything in the first sprint ends up doing nothing reliably. The constraint of a fixed scope forces a useful question: which one workflow, if it works correctly every time, makes this product worth using? Start there. Build that pipeline properly. Everything else is phase two.

Gating on human approval is a feature, not a workaround

There is a tendency to treat human-in-the-loop as a temporary fix, something to remove once the model gets better. I disagree with that framing. For a class of decisions, human approval is the right architecture permanently.

On Job Hunter, a daily job board and outreach engine that crawls over 185 career pages, the AI layer generates personalised outreach drafts. Those drafts are not sent automatically. The user reviews and approves each one. That is not a limitation of the model. It is the product design. The user's judgment is part of the value chain. Removing it would make the product faster and worse.

The same logic applies anywhere the output has real-world consequences: financial recommendations, legal classifications, public sector decisions. The model surfaces the answer. A person confirms it. That is not a workaround. It is accountability built into the architecture.

What breaks in the first two weeks

Every AI product I have built has hit the same wall in the first two weeks of real use. The model performs well on the inputs you designed for. It performs unpredictably on the inputs users actually send.

This is not a model problem. It is a distribution problem. The training data, the prompt design, the example inputs used during development, all of them reflect assumptions about what users will send. Real users do not read the documentation. They send partial inputs, ambiguous inputs, inputs in the wrong language, inputs that are technically valid but semantically broken.

The answer is not to make the model more robust in isolation. The answer is to build the pipeline so that low-confidence outputs are caught before they reach the user, flagged for review, and used to improve the system. That feedback loop is the difference between an AI product that degrades over time and one that improves.

Building that loop is part of what I scope into an MVP Sprint from the start. It is not a phase two concern. If you ship without it, you are shipping a product that will get worse as usage grows.

Where to go from here

If you are building an AI product and the architecture is not settled yet, the time to think about verification, approval gates, and failure paths is now, not after the first user complaint. I have written more on how this plays out across different domains in the rest of the notes.

If you have a specific workflow in mind and want to pressure-test the architecture before committing to a build, the Technical Due Diligence engagement is the right starting point. Fixed scope, two to three weeks, focused on exactly the questions that matter before you spend eight to twelve weeks building something you cannot easily change.