Skip to content

Process

Howanengagementactuallyruns.

No black box. This is the real sequence, including the parts where we might tell you to stop.

  1. Week 0

    A paid two-week pilot

    Every engagement starts here. A fixed fee, a defined question, and an artefact you keep whatever happens next. It turns a six-figure decision into a small one, for both of us.

    • One question we both agree is the riskiest part
    • Fixed price, agreed before we start
    • Ends with working code and a written recommendation
    • No obligation to continue — roughly one in five do not, which is the point
  2. Week 1–2

    Measure before building

    We assemble the eval set, map the failure surface, or model the data contracts — whichever the problem calls for. This is where most projects skip a step and pay for it in month four.

    • Access to a representative slice of real data
    • Two hours with whoever knows the domain
    • A baseline you can point at, however unflattering
  3. Ongoing

    Two-week slices, in your repo

    Work lands in your repositories from day one, reviewed by your engineers. Nothing is developed in isolation and handed over at the end — that pattern produces code nobody wants to own.

    • A demo every two weeks against the measured baseline
    • A written weekly note: what moved, what did not, what we are worried about
    • Your team reviews every pull request
  4. The end

    Handover, deliberately

    The engagement is designed to finish. We are not building a dependency, and a retainer that exists because nobody else can operate the system is a failure, not a business model.

    • Runbooks for the failures that will actually happen
    • A working session with the engineers taking it on
    • Thirty days of questions answered at no charge

How we behave

We will tell you when not to build it

Sometimes the honest answer is that the task is not reliable enough yet, or that the problem is organisational rather than technical. Saying so in week two is worth more to you than five months of billing.

Bad news travels fastest

If something is not working you hear it in the weekly note, not at the end. Every project has a week where the news is bad; the difference is when you find out.

Your engineers are in the loop, always

Every PR reviewed by your team. It is slower in month one and much faster from month three, and it means the system does not leave when we do.

Fixed scope, fixed price, where we can

Discovery and pilots are always fixed. Longer builds are usually time and materials, because pretending to know the scope of an unmeasured problem helps nobody.

Have a problem shaped like this?

Thirty minutes, no deck. Bring the thing that is not working and we will tell you what we would do about it — including when the answer is that you do not need us.

We reply within one business day