// The process //

Five steps, every time

The same five phases apply to every engagement — Audit, Sprint, or Bespoke. The depth of each phase scales with project complexity. The order never changes.

01
Discover
Map processes, identify opportunities, establish data reality
02
Architect
Design system, select models, define integrations
03
Build
Iterative development with staged milestones and testing
04
Deploy
Production handoff, documentation, knowledge transfer
05
Optimise
Ongoing monitoring, tuning, and improvement
// Phase 01 //

Discover

Discovery is not a formality — it is the work that makes everything else possible. We spend 1–2 weeks embedded in your operations, building an accurate picture of what actually happens in your business, not what the documentation says happens.

The failure mode we are avoiding here is the AI project built on assumptions. Every skipped discovery session becomes a wrong assumption in the architecture, which becomes a broken system in production. We take discovery seriously so we do not have to take re-builds seriously later.

What we do in Discovery

Structured interviews with your operational leads — the people who actually do the work, not just the people who oversee it. We ask about inputs, outputs, exceptions, volume, tooling, and the informal workarounds your team has built around process gaps.

What we need from you

Access to your operational leads for interviews (typically 2–4 people, 1 hour each). Access to representative data samples — documents, records, or system exports that illustrate the process. Access to your existing tooling for context. We do not need everything to be perfect — we need it to be real.

What you get at the end

A documented process map, a written assessment of AI fit for each opportunity identified, and a prioritised list of what to build — with a frank assessment of what will not work and why. For Audit engagements, this is the final deliverable. For Sprints and Bespoke builds, it is the foundation the architecture is built on.

Typical duration

1–2 weeks for an Audit engagement. For larger bespoke builds with more complex operations, Discovery may extend to 3–4 weeks. Duration is agreed at the outset and does not move without your approval.

System design decisions

We define the system boundary, component responsibilities, data flow, and integration points before writing code. This includes decisions about agent architecture (single-agent vs. multi-agent, tool design, memory strategy) and pipeline structure for RAG or automation systems.

Model selection rationale

Not every task needs the most powerful model — and using one unnecessarily adds cost and latency. We select models against your specific task requirements: reasoning depth, context length, cost per token, output format, and latency tolerance. We document the selection rationale so you understand the trade-offs made.

Integration mapping

We map every system your AI will need to interact with — APIs, databases, authentication systems, output destinations — and identify the integration approach for each. We raise potential blockers here, not mid-build. If an integration requires changes on your side, we identify it in this phase.

Risk and edge case planning

We identify the failure modes specific to your system before building it — what happens when the model produces an unexpected output, when the retrieval returns no relevant results, when an external API is unavailable. These scenarios are planned for in the architecture, not discovered in production.

// Phase 02 //

Architect

Architecture happens before code. We produce a written technical design that covers system structure, model selection, integration points, data flows, and failure handling — and we review it with you before development starts.

This phase exists because AI systems have properties that make early architecture decisions particularly consequential. The choice of retrieval strategy, context window management approach, or agent tool design is expensive to reverse once implementation is underway.

You receive the architecture document as part of your project deliverable. It becomes the technical foundation of your system documentation.

"We do not start building until both sides have reviewed the architecture and signed off on the approach. This is not a bureaucratic checkpoint — it is the point where we confirm that what we are about to build is what you actually need."

// Phase 03 //

Build

Development follows a milestone-based structure. Rather than delivering everything at the end, we define and deliver staged checkpoints — giving you visibility into progress and the ability to provide feedback before the next phase of development is locked in.

You are not expected to be passive during the build. We share working versions at milestone points, walk you through what has been built and why, and incorporate your feedback before moving forward. This is how we avoid building three weeks of the wrong thing.

Scope changes during the build are handled with a formal change process: we document the change, estimate the impact on timeline and cost, and get written sign-off before implementing anything outside the original scope.

Development approach

Iterative development against the agreed architecture. We build the core pipeline first, validate it against real data, then extend to edge case handling, integration wiring, and production hardening. No shortcut to "demo mode" — we build for production from the first line of code.

Testing approach

AI systems require evaluation beyond unit and integration tests. We build an evaluation suite specific to your system — measuring output quality, retrieval accuracy, latency, and failure rate against real data from your environment. You see the evaluation results at each milestone.

Iteration cadence

Weekly written updates throughout the build — what was built, what is next, any blockers or decisions that require your input. We do not go quiet for three weeks and then surface a system. You always know exactly where the project stands.

How you are kept informed

Milestone demos at agreed checkpoints. Written weekly summaries. A shared project tracker with current status, upcoming milestones, and any open decisions. We do not use opaque project management tools that require you to log into another platform — communication is direct and clear.

Production handoff

Deployment to your infrastructure, or to a cloud environment you control — not ours. The system runs under your accounts, with your API keys, connected to your data sources. After handoff, you can operate it without us. That is a design requirement, not a nice-to-have.

Documentation

Full technical documentation covering system architecture, component responsibilities, configuration parameters, integration details, prompt structure and rationale, and known limitations. Written for your technical team, not for us — clear enough that someone who was not involved in the build can understand and modify it.

Monitoring setup

We implement logging and monitoring for the production system — output quality sampling, latency tracking, error rate alerting, and cost monitoring. You can see how the system is performing in real-time without needing us to interpret it for you.

Knowledge transfer

A dedicated session with your technical team (and/or operational leads) walking through the system in full — architecture, configuration, how to extend it, what to watch for, and how to handle the edge cases we identified. This session is recorded and provided as a reference.

// Phase 04 //

Deploy

Deployment is not the end — it is where the system starts earning its value. We treat production handoff as a structured phase, not a handshake and an invoice. The goal is a system your team can operate confidently from day one.

Dependency on the original implementor is a risk for any production system. We actively design against it — through documentation that is complete, monitoring that is visible, and a handover session that transfers knowledge, not just access credentials.

After deployment, there is a two-week stabilisation period during which we remain available to address any production issues at no additional charge. After stabilisation, ongoing support is available through the Optimisation Retainer.

Source code ownership: You receive full, unrestricted ownership of all code produced during the engagement. No licensing restrictions, no usage fees, no requirement to maintain a relationship with us to keep the system running.

// Phase 05 //

Optimise

A production AI system in month six looks different from the same system in month one. Usage patterns reveal edge cases the build phase did not anticipate. Models from your AI provider update. Your operations evolve. The Optimisation Retainer is how you keep the system performing as the context around it changes.

The Retainer is optional — the system we hand you is designed to run without it. But organisations that want continuous improvement rather than point-in-time delivery benefit from having an AI partner who already knows their system in depth.

The Retainer also provides the foundation for scope expansion. When you are ready to build the next AI system, you have a partner who already understands your operations, your stack, and your constraints — and you do not need to repeat Discovery from scratch.

What ongoing improvement looks like

Each month: a performance review against the metrics established at deployment, targeted improvements to the prompt layer or retrieval configuration, analysis of any failure cases surfaced in production, and a brief written report summarising what was done and what was found.

Responding to model changes

When OpenAI, Anthropic, or another provider updates a model your system uses, we assess the impact, run evaluation against your system's test suite, and implement any adjustments needed. You do not have to track model deprecations or version changes yourself.

When to expand scope

The right time to expand is when the current system is stable and valuable, and you have identified the next highest-impact opportunity. We surface those expansion candidates during the monthly review. When you are ready to build, we scope the next sprint within the retainer engagement — no new sales process required.

// Constraints //

What we don't do

Knowing what a firm won't do is as useful as knowing what they will. These are not disclaimers — they are commitments.

We don't run open-ended engagements with no defined output

Every engagement has a defined scope, a defined deliverable, and a defined end point. Time-and-materials arrangements with no clear output definition are not how we work. If you cannot define what success looks like, we do the Audit first to establish that definition before any build begins.

We don't use your project to train junior developers

Your production system is not a learning environment for someone still figuring out how AI systems work. The people who scope the engagement are the people who build it. We do not hand off your project to junior team members once the sales conversation is over.

We don't recommend technology based on vendor relationships

Model and infrastructure recommendations are based on technical fit for your specific requirements. We have no referral arrangements or preferred vendor relationships that influence what we recommend. If the right tool for your project is a model we have never built with before, we learn it and use it.

// Start here //

Ready to start?

Every engagement starts with the AI Audit. Two weeks, $3,000, and you leave with a clear picture of what to build and what it will cost.