A written scope before anything is billed
The end state, what is explicitly out of scope, the price and the date. You approve it before work starts, and nothing outside it appears on an invoice later.
How we work
The scope changes. The sequence doesn’t. One week or eight, every engagement runs through the same four stages.
Scope and price fixed before we start, the work visible as it happens, and your team owning it at the end.
- 01Before we start
Scope
One call to work out which of the three services fits, what the end state is, and what it costs. You get a written scope with a fixed price and a fixed end date before anyone commits.
In practice
- A 30-minute call, no deck. You bring the problem in whatever state it is actually in.
- We come back with a written scope: the end state, what is explicitly out of scope, the price and the date.
- Nothing is billed until you have that document and have agreed to it.
- 02First week
Get close to the work
Interviews, shadowing the people who actually do the task, and a look at the systems and data involved. Assumptions get corrected here rather than at the end.
In practice
- Three to five interviews with the people who do the work, not only the people who own it.
- A look at the real data and the real systems, including the parts nobody is proud of.
- Where the engagement is a build, this is also when the evaluation set gets assembled.
- 03The middle
Build in the open
A weekly demo and a shared channel, whatever the deliverable is — a roadmap, a working system, or a team that has been trained. You see it as it takes shape, not at a reveal.
In practice
- A weekly demo of the working thing, at the same time each week.
- A shared channel with the people building it, not with an account manager.
- Every change measured against the baseline or the evaluation set agreed at scoping.
- 04Final week
Hand over
Documentation, a runbook and a working session with the people who own it next. Everything runs on your infrastructure and accounts, so there is nothing to migrate when we leave.
In practice
- A runbook and architecture documentation written for the engineer who inherits it.
- A recorded pairing session with the team taking ownership.
- An on-call window from us after go-live while your team settles in.
Commitments
What holds across all four stages. These are the same whichever service you engage us for, and they are in the contract rather than only on this page.
The same people throughout
Whoever scopes the engagement runs it. There is no handoff to a delivery team you have not met and no account manager between you and the build.
A demo every week, at the same time
Of the working thing, not of a slide about it. If a week produced nothing worth demonstrating, that is what you see, and we say why.
Everything on your accounts
Your cloud, your repositories, your CI, from the first commit. You can revoke our access at any point and lose nothing.
Your side
What we need from you. Short list, but each item on it has delayed an engagement at least once.
- A sponsor who can make decisions, available for about two hours a week.
- Access to the people who do the work, for three to five interviews of an hour.
- Read access to the relevant data and systems inside the first week — this is the single most common cause of delay.
- A named contact in security or data protection, early rather than at the end.
- Someone identified as the eventual owner, so handover has a destination.
If data access is going to be slow, tell us at scoping rather than in week one. We will sequence the work around it instead of stalling.
Get started
Let’s find out what AI is actually worth to you.
A 30-minute call, no deck. Bring the workflow that frustrates you most and we will tell you whether it is worth automating.
Typically replies within one business day.