AI sprint vs full build

The short answer

Start with a sprint when the question is “will this work here?”. Start with a full build when the question is “how do we run this at scale?”. If nobody in the room can describe, in one sentence, what the finished system does on a Tuesday morning, a sprint is the cheaper way to find out.

Side by side

Choose a sprint when

• The workflow is real and painful, but nobody has proven that a model can do the hard part reliably enough.
• You need something in front of a board, a client or a regulator before a larger budget is released.
• Two teams disagree about the approach and a working artefact would settle it faster than another workshop.
• Your documents or data are messier than anyone admits, and you want that discovered in week two rather than month five.
• You are evaluating a supplier and want to see how they work before committing to a long engagement.

Choose a full build when

• The workflow already works manually and the constraint is volume, consistency or staff time.
• Several roles need different views, permissions and hand-offs — that is a system, not a prototype.
• The output is binding: it goes to a customer, a regulator, an auditor or a payment run.
• Integration with a CRM, ERP or case system is the substance of the project rather than a nice-to-have.
• A comparable pilot has already been run, here or elsewhere, and the uncertainty is engineering rather than feasibility.

Why the sprint is usually cheaper overall

A sprint is not a discount on a build; it is insurance against the wrong build. The expensive failure mode in AI projects is not paying for a prototype that gets thrown away — it is six months of engineering aimed at a workflow that a model could never handle accurately enough, or that staff quietly work around. A sprint puts that discovery at the front, where it costs weeks instead of quarters.

The corollary is equally true: if the feasibility question is already answered, a sprint just adds a delay. Paying to re-prove something you know is waste dressed up as prudence.

What a sensible sequence looks like

1. Map the workflow, the owners, the data and the decision the system must make.
2. Sprint on the single riskiest part of it, with a measurable success criterion agreed in writing beforehand.
3. Decide on the evidence: proceed, change approach, or stop. Stopping is a valid and cheap outcome at this point.
4. Build in staged releases, each one usable, with the sprint artefact as the reference for behaviour.
5. Operate: monitoring, retraining or re-prompting, and a review cadence with the people who use it daily.

Questions worth asking any supplier

• What is the written success criterion for this sprint, and who signs it off?
• What exactly do I own at the end — code, prompts, evaluation data, infrastructure definitions?
• What would make you recommend that we stop?
• If we proceed, how much of the sprint is reused rather than rewritten?
• Who operates it after launch, and what does that cost?

A supplier who cannot answer the third question is selling you a build regardless of what the evidence says.

Nächster Schritt

If you can describe the workflow in a paragraph, that is enough to start the conversation. Tell us what is slowing the business down, or read the fixed-scope sprint in detail. See also: buy vs build and specialist studio vs staff augmentation.