Skip to content
Approach

Process risk is the risk you are actually taking.

You can evaluate our technical judgement from the work. What you cannot see in advance is how an engagement runs — so here it is: the shapes, the commercial models, and the principles we will not trade away.

How to start

Six fixed shapes

Each one states a duration, a price posture and what lands at the end. Most engagements begin with the two-week sprint or the five-day diagnostic, and both end with something written that you own whether or not the work continues.

Catalyst Sprint

2 weeks

A written decision and a working prototype for one bounded question.

  • A framing session that turns the question into a decidable one
  • A working prototype on your own data or your own estate
  • A written decision record with the alternatives and the reasoning
  • A costed plan for what follows, if anything should
Fixed price, agreed before the work startsStart with Catalyst Sprint

Architecture Diagnostic

5 days

An independent written assessment, a ranked risk list and a costed roadmap.

  • A read of the code and the infrastructure, not only of the documentation
  • Interviews with the people who operate it
  • The ranked risk register, each item with its blast radius
  • A management presentation of the findings

Platform Foundation

8–12 weeks

A production platform on your hardware or your cloud, handed over and operable by your team.

  • The cluster estate, built declaratively and owned by you
  • The platform layer: ingress, storage, secrets, policy, observability
  • The delivery path, with promotion and rollback
  • Runbooks, a written platform contract and a recorded handover
Fixed scope, milestone-billedStart with Platform Foundation

AI Workforce Pilot

6 weeks

One synthetic role in production, with its evaluation harness, its cost model and its human checkpoints.

  • The role chosen with you, on the criterion that its outcome is measurable
  • The pipeline built and deployed on your estate or on burst capacity
  • An evaluation harness with your own examples and your own grading criteria
  • The measured result, including cost per interaction and the decision on whether to keep it

Embedded Partner

Rolling, monthly

A senior engineer or architect inside your team, with a stated allocation.

  • An agreed allocation, working inside your own delivery process
  • Code, not only advice
  • A monthly written review of what moved and what did not
  • Knowledge transfer as a stated objective rather than a side effect
Monthly, cancellable with 30 days' noticeStart with Embedded Partner

Advisory Retainer

Rolling, monthly

A standing call on senior judgement for a team that executes for itself.

  • A scheduled weekly session plus asynchronous access
  • Design review on your own documents and code
  • Vendor and technology evaluations, written
  • Escalation availability for incidents and for decisions that cannot wait
Monthly, with a stated response commitmentStart with Advisory Retainer
Commercially

Four ways to buy

The shape above says what the work is. The model here says how it is bought and billed.

Fixed-scope project

When it fits

The problem is well understood and the risk is in the execution.

How it is billed

A defined outcome for a defined price, billed against milestones.

Embedded team

When it fits

You have the roadmap and lack the senior capacity to deliver it.

How it is billed

Monthly, by agreed allocation, cancellable with 30 days' notice.

Advisory retainer

When it fits

Your team executes and needs a challenger rather than a builder.

How it is billed

Monthly, with a stated response commitment.

Build, operate, transfer

When it fits

You are hiring the team that does not exist yet.

How it is billed

Milestone-billed through build and operate, with a fixed transfer date.

Principles

What we will not trade away

These decide arguments. When a deadline and one of these are in conflict, we will say so rather than quietly drop it.

01

The code is the source of truth

We read the system before we judge it. Every assessment we write is grounded in a read of the code and the infrastructure, never in the diagrams or the documentation alone.

02

Prove it, do not assume it

A migration is proven equal with an automated comparison, not with a spot check. A platform is proven reliable by its own failure drills. Nothing is reported green until a real run says so.

03

Deliverables are artefacts, not activities

You receive things you can hold: a running system, a written decision, a test lane, a runbook. If you cannot say whether it is done, we did not define it properly.

04

Leave the capability behind

An engagement that leaves your team unable to operate what we built has failed, regardless of what it shipped. Handover is a deliverable with its own acceptance criteria.

05

Write the decision down

Every consequential choice becomes a decision record naming the alternatives and the reasoning, so the same argument does not return next quarter with different people.

06

Own the whole line

Platform, data, models and architecture are one problem wearing four job titles. We take the whole line so nobody gets to hand the outcome to somebody else.