<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=326548402028168&amp;ev=PageView&amp;noscript=1">

How we work

Embedded from day one

The same people who assess your systems are the people who build inside them. Four stages, run as a loop, with you signing off at every gate.

Why this is different

The handover problem

Most consultancy engagements end at the point the hard work starts. You receive a recommendation, a roadmap, or an audit, and then the job of building the thing lands with the team that was already at capacity. The knowledge that produced the recommendation walks out of the building with the consultant.

We work the other way round. The assessment is real work, not a sales stage. The person who did it stays to build what it recommends. Nothing is thrown over a wall, because there is no wall.

That is also why we do not sell rip-and-replace projects by default. Replacing a platform is expensive, slow, and usually not the actual problem: the actual problem is normally the workflow running on top of it. The platform is never the fix. Redesign the workflow first, then automate it.

The method

Assess, embed, build, optimise

It runs as a loop, not a line. Optimise feeds back into Assess, because the second thing worth building is usually only visible once the first is live.

01

Assess

Find out what is actually happening, from the people it happens to. We map the workflow as it really runs: your stack, your data, the manual steps nobody has time to fix, interviewing the people who live it daily and the people downstream who inherit its output. The gap between those two descriptions is usually where the problem is.

You get: a written, prioritised assessment, yours to keep and act on, with us or without us. Gate: you decide whether to build, and what first. Measured by: baselines agreed here, before anything changes.

02

Embed

We work inside your systems, not alongside them. Access, context, your conventions, your approval routes. We fit the working rhythm you already run rather than adding a new layer of meetings.

You get: progress visible to your team continuously, not a status report every fortnight. Gate: scope and sequence confirmed in writing before the build starts. Measured by: time to first working output.

03

Build

Working software, shipped in pieces, in your live stack. Smallest useful thing first, with the discipline that makes automation trustworthy: error handling, monitoring, and approval stages where a person needs to make the call. Deterministic rules handle the predictable majority; the model is called only where it genuinely earns its place.

You get: deployed, working systems in your own accounts. Gate: you approve each increment before it goes live. Measured by: the Stage 1 baselines.

04

Optimise

Measure what's live, improve it, and make sure it outlasts us. Fix what the real world exposes, then document everything: how it's built, how to run it, how to change it, what to do when it breaks.

You get: measured performance against the baseline, and documentation good enough for someone who has never met us. Gate: continue, extend, or stop, and stopping is a legitimate outcome. Measured by: does it still run when we are not in the room?

What you keep

In every engagement

Working systems in your own accounts

Not on our infrastructure, not licensed from us.

Documentation written for your team

Not for us, good enough to pick up cold.

The assessment and the measures

The assessment is yours whatever you decide afterwards, with baseline and measured results so the value is arguable rather than asserted.

No lock-in

Nothing we build requires our continued involvement to keep running.

What we ask of you

What makes this work

Honest about the conditions for success, because engagements fail on these more often than on technical difficulty:

  • Access, reasonably quickly. Embedded work stops without it.
  • One person who can decide. Not a committee, a named point of contact who can unblock and sign off.
  • Time from the people who live the workflow. A few hours in Stage 1 saves weeks in Stage 3.
  • Willingness to hear that a tool is not the answer. Sometimes the finding is a process change and no software at all. That is a real result, and it saves money.

Questions

Common questions

How long does an engagement take?
It depends on scope, and we won't quote a duration before the assessment tells us what we're dealing with. The assessment itself is fixed-scope, so you know what you're committing to at the point of committing.
Do you replace our existing tools?
Usually not. We work with the stack you already run and improve it. Where a migration genuinely is the right answer, we say so, plan it, and run it, but that is a finding, never a starting assumption.
Who owns what you build?
You do. It is built in your accounts and documented for your team.
What happens if we want to stop?
You stop. You keep what has been built and the documentation for it. Nothing is designed to be un-leaveable.
Do you use AI in everything?
No. AI is used where it does something rules cannot: reading unstructured text, classifying ambiguity, drafting. For everything predictable, deterministic logic is cheaper, faster and easier to audit.

Start with the assessment

A short conversation first, to work out whether an embedded build is the right answer for you, including when it isn't.