Plan · Build · Deliver
Three phases, each with a defined output and a decision gate. You can stop, redirect or expand at every gate — which is what makes an AI budget defensible to the people who approve it.
What happens, in order
Most AI programs fail between phases, not inside them. The gates are the point.
Plan
Ranked opportunity assessment, readiness diagnosis, target architecture and a sequenced business case. Output: a roadmap a CFO can approve.
Build
Production engineering against the first increment — data, model, integration, security review, QA. Output: a working capability in your environment.
Deliver
Deployment, adoption, measurement and operating ownership. Output: a capability your team runs and a number that moved.
Compound
The next increment reuses the platform, governance and pipelines already paid for. Each cycle costs less than the one before it.
Plan
Planning exists to make the expensive decisions cheaply. Typically two to six weeks depending on scope, and deliberately short — a long discovery phase is usually a sign nobody has decided what success is.
What we do
- Opportunity assessment. Interview the business, map candidate use cases, and rank them on value, feasibility, data readiness and adoption risk.
- Readiness diagnosis. Assess data, platform, security, governance and skills across the pillars that actually block deployment.
- Target architecture. A modular, model-agnostic design that fits the systems you already run.
- Business case and sequencing. Effort, ROI and risk modeled per initiative, ordered so early increments fund later ones.
The gate
You leave Plan with a roadmap, a costed first increment and a named business metric. If the numbers do not justify proceeding, that is a successful Plan phase — and a fraction of the cost of discovering it eighteen months into a build.
Build
Build is where our delivery history matters most. We engineer the increment the way we engineer any production system, because that is what it has to become.
What we do
- Data and pipelines. The retrieval, quality and lineage work that determines whether the model is trustworthy.
- Model and application layer. Agentic workflows, retrieval-augmented systems or custom applications — behind an abstraction so the model stays swappable.
- Integration. Into the ERP, EHR, PMS, CRM or platform the work actually lives in. Usually the largest line item, and the one most estimates miss.
- Security and governance review. Access control, data handling, audit trail, human-in-the-loop boundaries, evaluation harness.
- QA and release engineering. Automated evaluation of model behavior alongside conventional test coverage.
The gate
Build ends with a working capability in your environment, evaluated against acceptance criteria set in Plan — not a demo on our laptops.
Deliver
Deliver is the phase most providers treat as someone else’s problem. It is where value is either realized or quietly lost.
What we do
- Deployment and cutover. Into production, with rollback, monitoring and a defined operating owner.
- Adoption and change management. Role-based training, an internal champion, and workflow redesign so the capability is used rather than avoided.
- Measurement against baseline. Reporting on the business metric agreed in Plan.
- Operating handover or managed run. Your team takes it, or we run it — explicitly chosen, not defaulted into.
Why this is a phase and not a footnote
An unadopted capability has negative value: you carry the cost and the maintenance without the benefit. Change management, training and adoption support are delivered as part of the engagement — see AI Success Services for the specific offerings.
How the engagement runs
Do we have to buy all three phases?
No. Plan is frequently bought on its own, and a number of clients take the roadmap and execute internally. Build and Deliver can also be entered directly if you already have a validated business case and architecture. The gates exist so each phase can be a separate decision.
How long does a first increment take to reach production?
For a scoped, single-workflow build with reasonable data access, weeks rather than quarters. The variables that actually drive the timeline are integration surface and data readiness — not model selection. Plan produces a specific estimate for your environment before you commit to Build.
Who owns the code and the models?
You do. Work product is yours, delivered into your repositories and your cloud accounts. We do not build dependency on a proprietary Xcelacore platform, and the architecture is deliberately designed so you can change providers — including changing away from us.
How does this work alongside our internal engineering team?
Our default is embedded, not parallel: our engineers work in your repositories, your ceremonies and your tooling, with your team reviewing the code. That is the Partnership Model — an extension of your team rather than a replacement for it.
Start with Plan
A short, costed planning engagement is the cheapest way to find out whether the rest is worth doing.