How we work

What an engagement actually looks like

Including the parts that are your responsibility, the costs that stay yours, and what you are left holding if we stop working together. These are the questions that decide whether a project goes well, and they are cheaper to answer now than in month three.

Seven stages

Discovery

We watch the workflow as it is actually performed and write it down, including the exceptions people handle without noticing. This is where most of the value of an engagement is decided, and it is the part that gets skipped.

What we need from you: A few hours of the time of the people who do the work, and a sample of real records.

Scope and acceptance

Before anything is built we agree what is in, what is explicitly out, and what evidence would mean it worked — or that it did not. Acceptance criteria written afterwards are a negotiation; written first they are a decision.

What we need from you: Somebody empowered to say yes, and to say no.

Implementation

Built in your repository from the first commit, in the open, with tests. You can read the history as it happens rather than receiving a delivery at the end.

What we need from you: A place to put it, and access to whatever it has to talk to.

Demonstration

Shown running against your data at intervals we agree, including the cases where it does badly. A demonstration that only shows the happy path is a sales call, not a checkpoint.

What we need from you: Whoever will actually use it in the room, not only whoever sponsored it.

Evaluation

Scored against a baseline on a dataset we agree up front, with the failures listed. If the result does not clear the criteria, that is the finding, and we say so rather than adjusting the criteria.

What we need from you: Agreement on what the baseline is, which is usually the existing manual process.

Deployment

To an environment agreed at the start, with deployment, rollback and "turn it off" each a single documented command. Rollback is tested, not described.

What we need from you: The target environment, and a decision about who holds its credentials.

Handover

A runbook, an operator guide and a named owner on your side who can run it without us. The test is somebody who was not in the project doing it unaided.

What we need from you: The person who will own it, available before the end rather than after.

The questions your procurement team will ask

Answered here so you do not have to extract them one at a time. Where something is genuinely decided per engagement, it says so rather than offering a comfortable default.

Who owns the source code?: You do. Work is done in a repository you own, from the first commit. If the engagement ends early, you keep everything committed to that point — there is no stage at which the work lives somewhere you cannot reach.
Who owns the cloud account and the credentials?: You do, wherever that is possible. We prefer to work in your account with access you can revoke in one action. Where we hold a credential during an engagement, it is written down which one and who revokes it at the end.
Who pays for third-party and model usage?: You do, and directly wherever the provider allows it, so the bill is visible to you rather than marked up through us. A pilot states its expected usage before it starts, and refuses work that would exceed an agreed allowance rather than silently spending past it.
What access to our data do you need?: The least that makes the work possible, agreed in writing before it is granted. Where a synthetic set with the same shape and the same defects will do, we prefer that — our own training material is built that way for the same reason.
What happens when the scope changes?: It is re-agreed, in writing, with its effect on the date and the fee stated at the time rather than absorbed quietly and raised at the end. Fixed-scope work stays fixed by changing the scope deliberately, not by stretching it.
What are we responsible for?: Access, a decision-maker who can answer within a day or two, and the people who do the work being available during discovery. Most engagements that go badly go badly here rather than in the code.
What happens after launch?: Support is a separate, explicit arrangement — hours, scope and response agreed in the contract. We do not imply open-ended support inside a fixed-price pilot, because that is a promise that gets broken the first busy month.
Do learners from your programme ever see our work?: No. The coaching programme runs on separate infrastructure: each learner works in their own private repository provisioned from a template, against synthetic data authored for teaching. No client repository, client credential or client record is reachable from it, and commercial delivery is done by the delivery team rather than by learners.

Tell us what happens today

One form, three required fields. An engineer reads it and replies with questions or a view on scope. If we are not the right people for it, we will say that too.

Discuss a project