The engagement lifecycle
Four phases. One accountable team, the whole way.
Every engagement, in every practice, moves through the same four phases. The phases are how we work; the practices are what gets built. The commercial structure mirrors the lifecycle — a fixed-scope entry point, project-based delivery with hardware pass-through where it applies, and a recurring managed service — so what you pay for at each step matches what the step produces.
Discover / Consult
↓ feeds phase 02
A shared, written understanding of the problem.
We start from your actual situation: the work worth doing, the data boundaries and compliance posture, the latency and reliability requirements, the budget, and what already exists.
This phase produces a written findings document and a recommendation — including, where it's true, the honest answer that the right move is to buy, to defer, or not to build at all, and what we'd do instead.
Commercial shape — Fixed scope, fixed fee
Discovery is a paid engagement, sold as a standalone deliverable with a defined scope, duration, and fee agreed before work starts. If the engagement proceeds to design and build, the discovery fee is credited against the project. Charging for discovery is deliberate: it's what lets an engineer — not a sales funnel — do the analysis, and the findings document is valuable to you even if you take it elsewhere.
Design / Spec
↓ feeds phase 03
A spec you could, in principle, take anywhere.
The recommendation becomes a spec: architecture, the build and deployment plan, integration points, hardware where applicable, evaluation criteria, and the operating plan — with trade-offs written down. For an agent system, that includes the deployment model and model routing.
In practice, we build it. But the spec is written so that's a choice, not a lock-in.
Commercial shape — Project-based, priced per milestone
Design and build are priced as a project once discovery has bounded the scope: fixed price per milestone — spec acceptance, integration complete, evaluation criteria met, production go-live — with payment tied to milestone acceptance, not calendar time. For genuinely open-ended scopes, time and materials with a not-to-exceed cap. Milestone-fixed pricing puts the estimation risk on us, which is where it belongs given that we wrote the spec.
Build / Deploy
↓ feeds phase 04
Acceptance against the spec, not against a demo.
We build the system the spec describes, deploy it on the infrastructure the engagement calls for, and validate it against the evaluation criteria agreed in design.
Where physical infrastructure is involved — an on-prem buildout or owned hardware — we sequence the software build in parallel with procurement, so it's ready when the hardware is.
Commercial shape — Milestones continue; hardware passes through
Build milestones run under the same project structure as design. Hardware is handled as a distinct pass-through stream: we either purchase on your behalf at cost plus a stated markup with vendor invoices available on request, or you purchase directly against our spec and we charge a procurement-support fee. Stated plainly, either way — we have no reason to spec more hardware than the workload analysis supports, and you can verify that we didn't. Scope changes after spec acceptance are priced as amendments, not absorbed silently and not disputed at the end.
Manage / Maintain
Go-live is the midpoint, not the end.
Software is living infrastructure: dependencies move, the platform underneath shifts, usage grows, and — for agent systems — the models drift. We own monitoring, upgrades and migrations, cost and performance tuning, and capacity planning — for as long as the system is in production.
Even where you take over day-to-day operation, as in an on-prem handover, the engagement continues in a maintenance relationship sized to what you've taken on. The team that wrote the spec is the team keeping it true.
Commercial shape — Monthly retainer, tiered to the offering
The managed service is billed monthly for the life of the system, at one of three tiers — Maintain, Operate, or Run — differing in scope and response posture, not in whether we stay engaged. Where we host, infrastructure costs are passed through and reported line-item monthly, separate from the service fee: you see what your system actually costs to run. On exit, you receive the spec, the runbooks, the test and evaluation harnesses, and a supported transition — the system is yours.
Managed-service tiers
Three tiers. The difference is posture, not whether we stay.
Maintain
Systems you operate day-to-day; we stay on call
- Monitoring and alerting owned by your team; we receive escalations
- Upgrades and changes advised and planned; you execute with our support
- Scheduled reviews — drift, dependencies, and security
- Annual cost and performance review
Operate
Shared operation, the split defined in the spec
- Monitoring split defined in the spec
- Upgrades, changes, and migrations executed by us for the parts we run
- Recurring reviews — drift, dependencies, and security
- Recurring cost and performance tuning
Run
Systems we operate entirely
- Monitoring, alerting, and incident response fully ours
- Upgrades, migrations, and changes executed by us
- Continuous review and regression checks
- Continuous cost and performance tuning
Engineering time beyond each tier's included allowance is billed at the same rate card as project work — no separate, surprising number.
How the streams combine
A typical engagement, commercially.
- 1
Discovery & consult — fixed fee, credited if the project proceeds.
- 2
Design & build — milestone-fixed project fee, plus hardware pass-through where the engagement involves physical infrastructure.
- 3
Managed service — monthly retainer at the tier matching the engagement, beginning at go-live, plus pass-through infrastructure costs where we host.
The entry point is always the same: a paid, fixed-scope discovery with a written recommendation — or the honest advice not to proceed.
Start with discovery