How we work
Every engagement has the same general shape: three to six months,
one or two core applications, a principal embedded with the
client team. Below you'll find the three areas the firm works in,
the four-step engagement structure, and what actually happens on
a first call.
Area 1 — AI-Augmented Dev-Ops
What it is. Fitting AI tooling into the
development pipeline so it actually reduces effort. Test
generation against existing codebases, assisted refactoring on
long-lived modules, automated review for the categories of
issues that suit model review (typing, common bug patterns,
style), and scaffolding or migration code where the patterns
are repeatable.
Teams usually call us in here for one of two reasons. Either a
CTO has approved AI tooling but six months later the
productivity numbers look the same; or individual engineers are
using AI assistants productively but the gains aren't
compounding into team-level throughput. There's a third version
too — refactoring is bottlenecked on engineer hours and the
codebase happens to suit AI tooling — but that one's rarer.
An engagement typically opens with a baseline measurement of
where engineering time is going across a representative team,
sprint by sprint and ticket type by ticket type. We pick two to
four categories of work with the strongest expected return,
implement the tooling and workflow changes for those, then
re-measure against the baseline at six and twelve weeks. What
teams walk away with is some combination of dev-month load
reductions on the targeted categories, workflow patterns the
team keeps using after we leave, and a baseline framework the
engineering organisation can apply to future tooling decisions
on its own.
Area 2 — AI-Ops Optimization
This area is about the economics of running AI in production.
Model selection against the actual quality requirements of the
task rather than against benchmark scores. Inference cost
reduction through caching, smarter routing between model sizes,
and quantisation where it actually fits. Infrastructure tuning
across the serving stack — autoscaling, request shape, retry
policies. The point is to treat the AI cost line as a real
engineering discipline instead of a usage-based bill that scales
with adoption.
How it usually starts. Inference costs are
growing faster than the revenue from AI features, model spend
has turned into a board-level conversation, or the team picked
an over-specified model six months ago and is now paying for
quality the actual task doesn't need. Sometimes AI features have
shipped without anyone building the cost-monitoring and
model-selection discipline that production AI demands.
We start with a measurement pass on the current cost structure:
model by model, feature by feature, request by request. We
identify the largest cost categories and the changes most likely
to move them. Then iterative implementation — caching layer,
smaller-model routing, request shape changes, infrastructure
tuning, in whatever order makes sense for the cost map. Each
change is measured against the cost baseline before we move on.
Engagements like this typically take 30–55% off monthly
inference spend on the targeted features, and leave behind a
model-selection framework plus monitoring on cost regressions
that used to slip through unnoticed.
Area 3 — Process Re-Engineering
Most engineering organisations don't have a tooling problem;
they have a flow problem. Process Re-Engineering is the work of
redesigning how work moves through the pipeline — ticket flow
and hand-off reduction, sprint structure and standup
discipline, coordination overhead between teams, and the gap
between "we use Jira" and "Jira tracks the actual work." This
area sells fewer tools than the other two, which is part of why
it's usually where the biggest gains live.
It tends to be the right intervention when the organisation has
grown but velocity hasn't scaled with headcount. Meetings have
multiplied to coordinate work that used to coordinate itself,
there are more hand-offs between teams than there were a year
ago, and senior engineers are spending more time in process
than in code. The block is rarely engineering complexity at
that point — it's coordination cost.
The work starts with observation: sitting in on standups,
shadowing tickets through their lifecycle, mapping hand-offs
and queue times. From there we pick the two or three
coordination patterns producing the most overhead and implement
changes with the team rather than handing them down. Ticket
structure, hand-off rules, meeting cadence, ownership
boundaries — whichever combination fits. Cycle time and
coordination time get re-measured against the baseline at the
end. The artefact teams seem to value most isn't any single
process change but the honest answer to "where is the time
actually going."
Engagements run three to six months. Scope is usually one or
two applications or teams. We won't take on the whole
engineering organisation at once — that's not a pilot, that's a
transformation programme, and it isn't what the firm does.
Fees split in two: a fixed-fee base for the engagement plus a
bonus tied to the agreed outcome metrics. The structure aligns
the firm's incentives with the client's. Numbers depend on
scope and get worked out on the first call.
We don't bill hourly, we don't sell dedicated headcount, and
there are no ongoing monthly retainers. The engagement model
is one shape on purpose.
Thirty minutes on a call. Nothing to prepare beforehand. We'll
ask what you're currently seeing in your engineering
organisation — the cost line, velocity, where modernisation
has stalled, whatever has prompted you to look at this. You'll
ask whatever you need to about how the firm works.
By the end, we'll both have a sense of whether there's a fit.
If there is, the next step is a one-page proposal describing
what we'd measure, what we'd work on, the duration, the fee
structure, and the outcome metrics we'd both agree on. If there
isn't, we'll say so.
The engagement model only works when the firm and the client
are both confident in the fit. If we don't think we can move
the metrics that matter for you, we'll say so on the call.
Book a discovery call →
