ServicesAI Decision Sprint
Before build money is committed, the AI Decision Sprint determines which opportunity has the strongest combination of business value, technical feasibility, organizational fit, and manageable risk, and whether it should be built at all.
Start a conversation →The common failure is not picking the wrong model. It is committing budget to a use case that was never going to survive contact with real data, real permissions, and real users, only to find out nine months later.
A use case can look obvious in a leadership meeting and still be a poor first build: the source documents contradict each other, the process differs by team, nobody owns the output, or the people expected to use it have no reason to change how they work. None of that shows up in a demo.
The Decision Sprint exists to surface those constraints while they are still cheap to act on, and to produce a defensible answer to a single question: what should we build first, and is it worth building at all?
What the work costs today in time, error, delay, or lost revenue, and what a realistic improvement is worth, stated as a range rather than a promise.
How the work actually happens: who does it, where handoffs break, which steps are judgment and which are retrieval, and how much the process varies by team.
Whether the documents, records, and systems that would ground the output exist, are current, are accessible, and agree with each other.
Whether the use case can be supported with available integrations, permissions, latency budgets, and operational constraints, tested rather than assumed.
Where the system could be wrong in a way that matters, who is accountable when it is, and what review, logging, and access control the use case requires.
Whether the people expected to use it have a reason to, who owns it after launch, and what would have to change in the operating routine for it to stick.
The Sprint ends with a clear position, not a menu of options. If the strongest candidate does not justify the investment, Celadon will say so and explain what would need to change for the answer to be different. A recommendation to wait, to buy something off the shelf, or to fix a process problem before automating it is a legitimate outcome, and a cheaper one than discovering it mid-build.
Depth follows the fee. A focused Sprint on one workflow and a broader Sprint across several candidates both end in a decision; they do not produce the same artifacts.
Agree the business area in scope, the constraints that are fixed, and the specific question the Sprint has to answer.
Interview the people doing the work. Trace the actual path of a task, including the exceptions and workarounds nobody documents.
Examine the real documents and systems. Establish whether the knowledge a system would need is present, current, and consistent enough to rely on.
Evaluate the scoped opportunity (or candidates in a broader Sprint) against the six lenses, with the reasoning written down so it can be challenged.
Present the decision, the evidence behind it, the principal risks, and the costed next step, or the case for not proceeding.
A Decision Sprint does not include working software. It is not a prototype, a proof of concept, or a demo environment. It is not a vendor selection exercise run on a vendor's behalf, and it is not an open-ended discovery retainer that expands to fill the calendar.
Celadon deliberately keeps discovery separate from a pilot. A prototype bundled into discovery obscures what the strategy work actually cost and is routinely used to pressure a larger build. The Sprint produces the decision and the evidence behind it; if a narrow proof phase is warranted, that is a Build phase with its own fee and acceptance criteria.
It also does not attempt to assess every function in the business at once. The Sprint is deliberately narrow: one business area, one decision, one recommendation, delivered in weeks rather than quarters.
The AI Decision Sprint is priced as a fixed fee in the $15,000–$40,000 range, set before work starts based on the number of candidate opportunities, stakeholders, and systems that need to be examined. There is no hourly meter and no discovery retainer that expands to fill the calendar.
If the recommendation is to build and you proceed into a Celadon Build phase within 90 days of the Sprint ending, the Sprint fee is credited in full against that first Build phase. You are never paying twice for the same decision work.
A build cannot be priced honestly until someone has looked at the data, the integrations, and the failure modes. That is most of what the Sprint produces, which is why the implementation phase that follows can be quoted as a fixed fee against defined acceptance criteria instead of an hourly estimate.
There is no obligation to continue, and no commitment to Celadon as the implementer. The decision record is yours. When a broader Sprint includes an architecture blueprint, evaluation plan, and phased roadmap, those artifacts are yours as well and can be used by an internal team or another firm.
Two to four weeks and a fixed fee, ending in a recommendation you can act on, including a recommendation not to build.
Tell us what you are evaluating, building, operating, or trying to get adopted. Email is the first step; if a call would be useful after we review the context, we will suggest one.
