The idea of a working AI prototype in 10 business days sounds like a marketing claim. It is not. What makes it possible is the combination of a fixed scope model, an experienced team, and a sprint structure that has been deliberately designed around the specific constraints and decisions of an AI build — not a generic agile sprint repurposed for AI work.
Here is what the Prototype Sprint actually looks like, day by day, and what clients typically take away from Day 10.
What "fixed scope" actually means — and why it matters
The phrase "fixed scope" makes some clients nervous. It sounds like limitation. In the context of a prototype sprint, it is the opposite: it is what makes the guarantee credible.
A fixed scope sprint means that the boundaries of what will be built in the two weeks are agreed and locked at the start of Week 1, and that everything in those two weeks is directed toward delivering within those boundaries. It does not mean the prototype cannot evolve as learning happens — discovery during build always produces new information. It means that when new information arrives, the team makes scope decisions based on what can realistically be delivered in the remaining time, rather than letting scope expand to accommodate every new idea.
For clients, this is valuable because it removes the primary risk of an open-ended AI build: the prototype that is 80% done after four months. Fixed scope means you know what you are getting and when. It also makes the go/no-go decision on Day 10 genuinely useful, because you are evaluating a complete and coherent thing rather than a work-in-progress.
Week 1: scope, technology, architecture
Week 2: build, refine, and the Day 10 demo
"The best Day 10 demos are not the ones where everything works perfectly. They are the ones where the client has enough information to decide — with confidence — what to do next."
What clients typically build in their first sprint
The most common first-sprint prototypes fall into a small number of categories. AI-powered document processing and extraction — taking unstructured documents and producing structured, usable data — is the most frequent. AI-assisted customer communication tools — drafting responses, categorising queries, routing them appropriately — are common in service-heavy organisations. Internal knowledge and search tools, where an AI layer sits on top of existing documentation and knowledge bases, represent a growing category.
What these have in common: they solve a problem that is clearly defined, they have data available that can be used to test the AI's performance, and they produce outputs that can be evaluated by a human reviewer within the sprint window. These constraints are not limitations — they are selection criteria that make the sprint successful.
What separates a useful prototype from a demo
A demo is built to impress. A prototype is built to inform. The difference matters enormously when the go/no-go decision arrives on Day 10.
A useful prototype has been tested against real inputs — not just the curated examples that make any system look good. It has documented failure modes: the inputs it handles poorly, the edge cases it cannot yet manage, the assumptions embedded in its logic. It produces outputs that can be evaluated against a standard someone in the organisation actually understands and cares about.
A demo-only prototype can be impressive on Day 10 and generate budget approval for an MVP that then fails to deliver — because the approval was based on best-case performance, and the real-world inputs are messier than the demo inputs. The Prototype Sprint is specifically structured to avoid this outcome. The go/no-go assessment is an honest document, not a sales pitch. Its job is to help the client make the right decision, even if the right decision is to pause.
Ready to build?
The Prototype Sprint is a 2-week fixed-scope engagement. Zero recruitment, zero procurement. A functional prototype, complete technical documentation, and a go/no-go assessment — in 10 business days.
Start a Prototype Sprint →