A short, intensive validation session for product teams considering AI but still unsure whether the problem genuinely lends itself to it. From problem framing through use-case shortlisting and model selection to a clickable prototype that we test with real users, including technical feasibility, data reality and AI Act classification. The end of the sprint is a substantiated go/no-go, not yet another Miro board.
An AI design sprint is a concentrated validation session in which we work with your product and business team to put an AI idea through, in a short time, all the questions that would normally only be asked after an investment. We work in a hybrid of the classic Design Sprint format from Google Ventures (Jake Knapp) and an AI feasibility check: problem framing, user insight, sketching, prototype and testing along one clear line, with technical feasibility, model choice and compliance built into every phase.
A standard Design Sprint asks questions such as "do users actually want this" and "does this flow work". An AI design sprint does that too, but adds three questions that are decisive for AI concepts. One: is the problem suitable for AI at all, or are you in fact looking at an if/else rule that is being made smarter through automation rather than a model. Two: which approach fits, an LLM, classical machine learning, vector search or a combined pattern. And three: is the data reality in order, does the data you need exist, is it accessible, and is it of a quality with which a model can genuinely work.
The sprint is therefore the bridge between a broader AI business training (in which your team learns what AI is and where it can land) and a full AI implementation project (in which we put a validated concept into production). Training opens up thinking, a project delivers; a sprint chooses. Whoever jumps from training straight to a project without a sprint commits budget to a use case that later gets stuck on a data assumption that did not hold or a regulatory question nobody asked.
For those who don't yet have a clear view on the broader question of "which AI direction should we strategically pursue", an AI consultant engagement is often a more logical first step. The sprint itself assumes you already have one concrete candidate use case on the table — not "something with AI somewhere", but a specific problem where you suspect an AI solution might fit. Only then is the sprint efficient.
A sprint is worthwhile if you have a concrete candidate use case but are still uncertain about one or more of the typical pitfalls. A few patterns we see often.
You have a process that is slow, error-prone or disproportionately manual, and your team is thinking about AI. Before investing, you want to know whether a model would genuinely add value — or whether you actually need a process redesign, a rules-based system or a better search function. Not everything that is tedious is an AI job.
An LLM is tempting because it seems capable of everything. Classical machine learning is often cheaper and more stable where recurring patterns appear. Vector search solves a specific class of problems elegantly. During the sprint we map out the right approach based on your data, latency requirements and cost model.
On paper, your organisation has the data you need. In practice, it is spread across five systems, inconsistently structured, or simply lacks the signal the model requires. The sprint raises this question on day three rather than on day eighty of an implementation.
Since the AI Act came into force, every use case falls into one of the risk categories (prohibited, high, limited, minimal). The classification directly determines how much work surrounds it. In a sprint you get a provisional classification on the table, along with a picture of what the Article 9–15 requirements would mean for your specific case.
Management wants "something with AI"; the team doesn't know what outcome is expected; IT wonders where this lands in the architecture. A sprint forces everyone into the same room to make the same assumptions explicit — with a validated prototype as a shared reference.
An AI implementation is a serious investment. A sprint is your gate moment: you decide on the basis of evidence (users, prototype, technical check) whether to proceed to an implementation project. Both outcomes are valuable.
From the outside, an AI design sprint at Appfront looks like a design sprint — five phases, structured days, a prototype at the end. Under the bonnet, three choices differ from a classic Knapp sprint.
In a standard design sprint you mainly test desirability: do users want this? With us, technical feasibility runs alongside from day one. Which model, which data, which latency, which cost per inference. A prototype that is desirable but technically unfeasible is still a no-go — and it's better to hear that on day five than in month three.
The AI Act classification is provisionally set on day one and sharpened on day four as the use case takes concrete shape. A high-risk classification directly changes the scope: different requirements for documentation, logging, human oversight and robustness. We factor that into the go/no-go decision — not as a closing item, but as a variable.
The sprint prototype is not a clickable Figma mock. We build a working prototype with a real AI API behind it (Anthropic Claude, OpenAI or open-source), a UI mock in Streamlit or v0, and a minimal flow in which users actually receive answers. That changes what you learn from the user test.
Five phases at the heart of the Knapp format, with an AI layer in each phase. We work in a focused block rather than scattered working groups, so the whole team tackles the same pieces at the same pace.
We open with the classic Knapp question: what is the problem, and what would success look like over a longer horizon. For AI concepts we add two sharper questions. First: who exactly is the user of the AI system: the end customer, the employee, or an agent in another system? Second: which decision or action does the system change, and how would you measure whether that decision becomes better, faster or more consistent?
We map the end-to-end process into which the AI system must fit, and identify exactly where the model comes in. We then draw up a short list of possible AI approaches for that specific point: an LLM with or without RAG, classical ML, embedding search, rule-based, or hybrid. Often two candidates remain, which are weighed against each other in phase 03.
The choose phase combines three trade-offs. We choose the model pattern (which type of AI and which specific model family), we test the data reality (do we have it, at what quality, and under what processing conditions), and we record the AI Act classification (prohibited, high, limited or minimal risk). Together these three set the direction for the prototype. Undiscovered data defects or an unexpected high-risk classification surface here, not only during implementation.
We build a functional prototype that a user can genuinely use. For LLM use cases we connect to Anthropic Claude or OpenAI via the API; for specialised use cases we work with a suitable model. We build the UI quickly in Streamlit, v0 or a similar layer; integration flows in n8n or Make. The aim is not polish but realism: a real prompt, real data, a real model response and a UI that gives users enough context.
A handful of real users, be they your customers, your employees or the stakeholders who will work with the system, go through the prototype in a structured session. We record desirability (do they find it valuable), usability (can they work with it) and trust (do they believe the output) separately. For AI systems, trust is often the real bottleneck: not whether it works, but whether people dare to trust it.
After the tests we hold the findings against the three sprint dimensions (desirable, technically feasible, compliant) and formulate a reasoned go/no-go. On a go: a follow-on proposal with phasing, vendor and architecture direction, and an initial investment estimate. On a no-go: an honest overview of what the blocker is. No obligation to proceed from the sprint.
A sprint needs to be fast — not six weeks waiting for a dev team to put together a mock-up. The toolstack is optimised for speed, with the option of a clean transition to production architecture once you give the go-ahead.
For most sprint prototypes we work with the Anthropic Claude API or OpenAI. Where the use case calls for it, we also consider Google Gemini, Mistral or an open-source route. That way the concept doesn't depend on a single vendor.
A sprint prototype doesn't need to be polished, but it does need to feel real. We build UIs in Streamlit (quick Python prototyping), v0 (Next components in minutes) or a lightweight custom app built on existing UI libraries. The goal is a mock-up that doesn't get in the way of user testing.
Many AI use cases depend on what happens on the periphery: fetching data, placing output somewhere, sending a notification. We build those flows quickly in n8n or Make, so we can test the complete pattern without a production integration. Once you give the go-ahead, we translate the flow into the right architecture.
For AI concepts, it is crucial that the sprint is led by people who actually build AI systems — not by agency strategists who only know the model from slides.
The sprint is led by people who have worked on a production AI system this very week. The prototype follows the same code style and architectural choices as a real project — not throwaway work, but a focused first version.
No reseller deal with Anthropic, OpenAI, Microsoft or Google. We choose the model that suits your use case, and we will honestly tell you when open-source is a better choice than a frontier API.
The AI Act runs as an overlay across the entire sprint, not as a separate paragraph in the report. For clients with sector-specific regulation (healthcare, financial, public sector), we bring in a compliance specialist where needed.
There is no standard curriculum. We shape the plan from a short pre-sprint call: the nature of the problem, the sector, data and systems, stakeholders. The five phases remain; how each phase is filled in varies per assignment.
The sprint delivers a set of tangible outcomes that together form a package you can use for the decision moment — for your team, your management board, your board of directors.
The EU AI Act changes what an AI pilot may do, and what it must do in production. A sprint that ignores the Act delivers a prototype that is legally unusable. We take the Act into account from phase one, not as a barrier but as a design constraint.
In phase 01 we draw up a provisional risk classification based on the problem framing. In phase 03, when the model pattern and data become concrete, we sharpen that classification, because the precise shape of a use case can tip between limited and high risk. For a high-risk classification the scope shifts: articles 9 to 15 require a risk management system, data governance, technical documentation, logging, transparency towards users, human oversight and robustness, and we factor those requirements directly into the feasibility assessment.
We also work out the link with the GDPR, the need for a DPIA and, for financial institutions, DORA. For sector-specific regimes (NEN 7510 in healthcare, the assessment framework for public bodies), we bring in the relevant references. The report includes a section you can pass directly to your legal or compliance officer; for a deeper treatment, this ties into our AI development approach.
What the sprint does not do is produce a formal DPIA or audit report: that belongs to implementation, not validation. What it does do is prevent you from building on an assumption that, legally speaking, already ruled out the application in that form. A lot of wasted effort sits in the gap between "we heard it was allowed" and "it should have been built the way the Act prescribes".
A team wants an internal assistant that helps lawyers or consultants work through large case files. Sprint question: can an LLM with RAG solve this, or is targeted hybrid retrieval a better route? Output: a prototype on one sample case file, tested with three professionals, with sharp conclusions on hallucination risk and source attribution.
A service organisation is considering first-line triage by an AI agent. Sprint question: is this a chatbot problem, a classification problem, or a human-in-the-loop problem? Output: a prototype that routes 50 real enquiries, with an evaluation of precision, frustration risk and escalation path, plus an AI Act classification for this category of use case.
An operator is considering a model to support daily decisions such as scheduling, pricing or allocation. Sprint question: is this an ML model or an LLM application? Output: a prototype on historical data, tested with the people who make the decision today, and a clear distinction between "advice" and "automation".
A half-hour introductory call in which we go through the candidate use cases you have in mind, the uncertainties around problem fit, approach, data or compliance, and how a sprint can give the sharpest answer to them. No obligation. Afterwards we send you an outline with phasing and transparent pricing.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
