EnquiryTalk to Our Engineering Team

Forward-Deployed Engineering

One workflow, from prototype to production, in six weeks.

One named senior engineer joins your team, builds one workflow against your real records and cuts it over to real traffic. The sprint ends with a signed runbook and a team that can run it.

Book a scoping callHow the six weeks run

TermsScope, timing, staffing and commercial terms are agreed per engagement, in writing.

Duration
Six weeks
Team
One named senior engineer
First pull request
Day seven
Ends with
A signed runbook

Fit

Who it is for

The sprint is for you when

  • There is one workflow you want in production and a date it matters by
  • A prototype or a clear idea of the workflow already exists
  • Real access to real systems and records can be granted in the first week
  • Someone on your side owns the outcome and can clear a blocker in a day
  • Your team can take the handover: at least one engineer who will run it

It is not when

  • The workflow has not been chosen yet; the Readiness & Scoping Sprint comes first
  • Access will take a quarter to arrange
  • The problem is a research problem no model yet solves
  • You need capacity on a backlog rather than one outcome
  • There is nobody to hand the system to at the end

Week by week

How the six weeks run.

Six phases, each ending in something you can hold. The diamonds are the gates: scope signed, cut over, handed over.

W0W1W2W3W4W5W6

  1. Scope

    W0

    A one-page scope: the workflow, the metric, the owner, the exit gate

  2. Embed

    W1

    Access granted, repository cloned, a first pull request merged by day seven

  3. Prototype

    W2

    The workflow running on your stack behind a feature flag, and a golden set of real cases with known answers

  4. Build

    W3–W4

    Connectors to the system of record, the review queue, the audit trail and a suite that passes on the golden set

  5. Cut over

    W5

    Real traffic at real volume, rollback armed, monitoring live

  6. Hand over

    W6

    A runbook your engineers have executed, and the decision record, signed

Week two is the last week anything runs on sample data. From week three, every run is against your records.

TermsScope, timing, staffing and commercial terms are agreed per engagement, in writing.

What exists at the end

Six things, none of them a slide.

The sprint is complete when every item on this sheet is ticked by your side, not ours.

END OF SPRINT

  1. The workflow in production

    Running on real traffic under your account, with rollback armed and monitoring live.

  2. The repository

    Every commit in your repository, reviewed by your reviewers, intellectual property assigned before week one.

  3. The evaluation suite

    The golden set, the scoring harness and the regression run, wired into your pipeline.

  4. The runbook

    Deploy, rotate credentials, retrain, roll back, escalate; executed by your engineers in the handover dry run.

  5. The decision record

    Each architectural decision, the options considered and why one was taken, dated.

  6. The owner who has run it

    One named engineer on your side who has released, rolled back and retrained the system without us on the keyboard.

How the sprint is run

Four rules.

They keep six weeks from becoming twelve. Each is agreed at scoping and holds until the runbook is signed.

  1. The scope does not grow

    One workflow, one metric, one owner, on one page. Anything discovered along the way is written down for the next sprint, not added to this one.

  2. Access is the first blocker, so it is cleared first

    Repository, systems and records are requested on day one. If access is not real by the end of week one, the sprint pauses and the clock with it.

  3. Nothing ships that has not been scored

    The golden set is agreed with the people who do the work by the end of week two. Every candidate is scored against it before it reaches a user, and the score is what earns the cut-over.

  4. Your team does the handover, we watch

    In the last week your engineers perform a release, a rollback and a retrain with our engineer in the room but not on the keyboard. If that does not go cleanly, the sprint is not finished, whatever the calendar says.

TermsScope, timing, staffing and commercial terms are agreed per engagement, in writing.

Specified

The sprint, specified.

The terms as they stand before the first call. Scope moves the detail; it does not move the shape.

Duration
Six weeks from the day the scope is signed
Start
A scoping call, then a one-page scope agreed with the owner of the outcome
Engineer
One named senior engineer, full time, met before you sign
Cadence
Your standups daily; a written report to the owner weekly; a demonstration on real records at each gate
Access needed
Repository, the system of record, real records and a person who can approve a pull request
Where the work happens
In your repository and your cloud account; on site for scoping and embedding where the work needs it
Evaluation
A golden set agreed by the end of week two; every release scored against it
Cut over
Week five, on real traffic, with rollback armed and monitoring live before the switch
Handover
Week six: runbook, decision record and a dry run performed by your engineers
If it slips
For reasons on our side, we stay until the gate is met at no further fee; for access or decisions on yours, the clock pauses and we write down where it stands

TermsScope, timing, staffing and commercial terms are agreed per engagement, in writing.

Questions

Asked about the sprint.

Do we need a prototype before the sprint starts?

No. A clear idea of the workflow is enough; week two builds the prototype on your stack. If the workflow itself has not been chosen, the Readiness & Scoping Sprint comes first and ends with a scope this sprint can start from.

What does the engineer need from us in week one?

Repository access, access to the system of record and real records, a seat in your standups and one person who can approve a pull request. Access is what causes slippage, so it is requested on day one.

Can the scope change during the sprint?

The workflow, the metric and the owner do not change. What is learned along the way is written down for the next sprint. That is how six weeks stays six weeks.

What does cut-over involve?

Real traffic at real volume, with rollback armed and monitoring live before the switch is made. The golden-set score is the argument for going ahead; if it is not passing, the cut-over waits.

What happens after week six?

Your team runs the system; the runbook and the decision record are theirs. Our engineer stays on call for what was built for an agreed period, then steps back. Managed Operations exists if you would rather we keep running it.

How is the sprint priced?

As a fixed fee, agreed before week one against the written exit gate. There is no hourly billing and no invoice for a gate that was not met.

TermsScope, timing, staffing and commercial terms are agreed per engagement, in writing.

Forward-Deployed Engineering

Where this offering sits.

Start

Six weeks from the first call,one workflow runs in production.

Book a scoping call; you leave it knowing whether the workflow fits and what it would take.

Book a scoping callAll offerings