Skip to main content

How we work

Frame, Prove, Build, Hand over

Four phases with an exit agreed at the start. The last part is the one that changes how the first three are built.

Engagement methodFour sequential phases. Frame, one to two weeks, produces a feasibility note, risk register and costed options. Prove, three to six weeks, produces a thin vertical slice running on the client's infrastructure with an evaluation baseline. Build, eight to sixteen weeks, produces a hardened system with test suites and runbooks. Hand over, two to four weeks, leaves the client's team operating the system with an agreed exit plan.01 · 1–2 weeksFrame
Feasibility note, risk register, costed options
02 · 3–6 weeksProve
Thin vertical slice on your infrastructure, evaluation baseline
03 · 8–16 weeksBuild
Hardened system, test and eval suites, runbooks
04 · 2–4 weeksHand over
Your team operating it, exit plan agreed

01 · 1–2 weeks

Frame

Establish what is actually constrained, what success would look like, and whether we should proceed at all.

  • Inspect the data and infrastructure directly rather than relying on documentation.
  • Classify risk against the frameworks your regulator cares about.
  • Agree the exit criteria in writing, before any code exists.
  • Cost the options, including doing nothing.

Out · Feasibility note · Risk register · Costed options · Written exit criteria

02 · 3–6 weeks

Prove

Get one thin end-to-end path running on your infrastructure, with measurement attached from the first week.

  • Build the narrowest slice that touches every layer, including identity and logging.
  • Construct the evaluation set with your subject-matter experts.
  • Deploy into your environment early, so integration pain surfaces now rather than in month four.
  • Record architecture decisions as they are made.

Out · Working vertical slice · Evaluation baseline · Architecture decision records · Revised estimate

03 · 8–16 weeks

Build

Turn the slice into something that can be operated, audited and changed by people who were not there.

  • Harden identity, authorisation, observability and release.
  • Extend evaluation into a regression gate that can block a merge.
  • Load-test against your peak, not your average.
  • Security review, adversarial testing and rollback rehearsal.

Out · Deployed system · Regression gate in CI · Runbook from the incident log · Security review record

04 · 2–4 weeks

Hand over

Demonstrate (not assert) that your team can deploy, diagnose, evaluate and explain the system.

  • Your engineers drive; we observe and take notes.
  • Injected failure in staging, handled by your team.
  • Your team extends the evaluation set and interprets the result.
  • Final documentation written wherever they hesitated.

Out · Demonstrated capability · Completed runbook · Agreed support arrangement, if wanted

Who is on the team

Not everyone is present throughout. The composition changes by phase, and the governance specialist arriving in Frame rather than at go-live is the single change that most improves an outcome.

RolePresent fromWhat they own
Engagement leadAll phasesOwns the outcome and the honest status report. Usually also writing code.
AI engineerProve onwardServing, retrieval, tool integration, and the software engineering around the model.
Data scientistFrame onwardEvaluation design, adjudication process, agreement measurement, analysis.
Platform engineerProve onwardDeployment path, observability, release and rollback, in your tooling.
Governance specialistFrame onwardRisk classification, oversight design, evidence pack.
Data engineerAs neededPipelines, contracts, lineage where the substrate needs work first.

Working agreements

  • · We work in your repositories, under your review process, with your standards. Not in a parallel codebase handed over at the end.
  • · Architecture decision records for anything material, including rejected options and what would justify revisiting them.
  • · A weekly demonstration of working software, not a status deck.
  • · Scope changes are visible and costed. Nothing gets quietly added or quietly dropped.
  • · Bad news travels immediately. A slipping estimate is more useful in week three than in week nine.

When we say no

We decline engagements where an on-premises approach is clearly the wrong answer and a hosted service would serve you better; where the requirement is an agent with standing authority to take irreversible action without human oversight; where the timeline only works if evaluation is skipped; and where the real problem is a data platform that needs fixing first.

Start with the constraint.

Most of these projects are shaped by what you cannot do rather than what you want. Data that cannot leave the estate, a model you cannot host with a third party, a decision somebody has to justify to a regulator. Tell us yours and we will say honestly whether we can work inside it.