The forward deployed engineering process, step by step
Six stages, from the first afternoon on the floor to a system your team runs alone. Each stage ends with evidence you can check.
Written by the Verne engineering team.
Last reviewed
Discover: learn how the work is really done
The written procedure describes how the work should run. Discovery finds how it does run, where the time goes, and which one number will prove the fix worked.
The first 48 hours
Meet the people who do the work before any technical discussion. The first 48 hours decide how much they will show you, and psychological safety decides whether they show you the real process or the official one.
Shadow sessions
Sit beside each role, as an apprentice rather than an inspector. A shadow session catches the double entry, the glance at a side note and the screen people sigh at. Every workaround is shadow IT worth writing down.
Time every step twice
Time accounting records what the procedure says and what a stopwatch shows. The gap is SOP drift. By the bottleneck rule, a step at twice its procedure time is the first suspect.
Map today and the target
As-Is and To-Be maps sit side by side, with the exceptions drawn in, because most of the cost lives off the happy path.
Agree one number
A falsifiable success metric and its baseline: success means X falls from A to under B, measured by a log you already trust.
Ship a first fix
One quick win in the first week or two, picked by minutes lost a day. It proves the team can change things, and it pays for attention.
Time one of your processes
List the steps, what the procedure says each takes and what a stopwatch shows. The workbench flags the bottlenecks, picks the first fix and writes the metric.
- minutes lost a day across all steps
- 575
- steps at twice their procedure time or more
- 3
First fix: Matched to order and delivery note. It loses 200 minutes a day.
Success means matched to order and delivery note falls from 11 minutes to under 3 minutes an item, measured by the timestamps in your system of record.
The discovery audit
Eight checks run before anything is built. A gap in any of them becomes a named dependency in the plan, with an owner and a date.
- People and trust
- Who have we sat with? Who still distrusts the project, and whose job might it change?
- Procedure against reality
- How does the written procedure describe the work, and how is it really done?
- Time accounting
- Procedure time and stopwatch time for every step. Which steps take twice as long or more?
- Metric and scope
- Is the one-line metric written down, and is the scope boundary signed?
- Privacy and compliance
- Which data must stay inside your systems, and which regulator, auditor or customer rules apply?
- Network and hardware
- How often does the connection drop? What servers, memory and storage are available?
- First fix
- Which bottleneck can be fixed in the first week or two, and how many minutes does it return?
- Handover plan
- Who is the shadow partner, who owns the runbook, and when is the fire drill?
Scope: agree what phase one covers
A scope boundary of one or two pages names the workflow, the metric, the systems touched and what is left out. It is signed before the build starts.
New requests are not refused. Each one is checked against the metric: if it moves the number, it joins the build; if not, it goes on the phase-two list with a date and an owner. That is how scope creep stops without anyone saying no.
Deploy: access, boundaries and where it runs
The team works through scoped access: named accounts with only the permissions the work needs, which you can remove at any time. A decision boundary in writing says what the engineers decide alone and what needs your approval.
The system runs where your rules say it must: in the cloud, on your own servers, or a hybrid that keeps sensitive work on site. The team works your business hours when you need it to.
Build: one working loop, tested before it ships
Business rules come from the expert’s desk. In a domain sprint the expert walks through one real example, and their own numbers become a test before any code is written.
For AI features, the evaluation harness comes first: eval before build. A golden dataset of real, labelled cases runs on every change, and a release ships only when it clears the ship gate agreed with you.
Coding agents speed the work up inside three guardrails: a locked schema, nothing new installed without approval, and tests written first. Engineers read every change, so there is no vibe coding and no code drift.
Rules decide what the business already knows; a model reads only language and images; and a person approves anything that moves money or records. Every release checks its own health and rolls back on failure, a self-healing deploy.
Run a release through the gate
Pick a candidate change. It runs 24 real invoice cases, the gate passes or blocks it, and a release that fails its health check after deploy rolls back on its own.
v14 · Clearer prompt
Valid output 24/24 · Correct 23/24 (96%)
Wrong answer: Multi-page invoice.
- The pipeline runs when this figure is on screen.
For your engineers
The ship gate is configuration your team can read. The pipeline scores the golden dataset and blocks a release below the gate, so the last passing version stays live.
ship-gate.yaml · example
# ship-gate.yaml · checked by the pipeline before every release
workflow: supplier-invoice-matching
golden_dataset: eval/invoices-golden.jsonl # real cases, labelled by your team
gate:
valid_output: 1.00 # every output parses into the typed record
field_accuracy: 0.95 # agreed with your finance lead in the diagnostic
must_route_to_person:
- bank_details_changed
- amount_over_approval_limit
on_fail: block_release # the last passing version stays liveWrites to your systems carry idempotency keys, so a retry after a timeout never posts twice. Approvals bind to the exact action the reviewer saw, on a screen the model cannot reach, and each decision is added to the golden dataset.
Idempotent writes · three-way matching · human approval steps
Transfer: your team runs it without us
Handover starts in week one. A shadow partner from your side works beside our engineers every day, so the truck factor on your side rises with every week of the build.
Before we step back, your team rehearses recovery in a fire drill, using only the runbook. Then comes the handover test: two weeks of your team running everything while we answer only when asked. The code repository and IP are handed to you at full delivery.
The one-page runbook
- How to start, stop and restart the system
- Where the logs are, and what a healthy line looks like
- The first three things to try when it hangs
- When to call for help, and who to call
Run and improve: keep it used, keep it healthy
The first two or three weeks after go-live are hyper-care: problems are found in the logs and fixed before you notice them. After that, health checks raise one alert per incident, so a full disk is never a silent failure.
Uptime is not the measure that matters. Adoption rate and stagnant days show silent churn months before anyone complains, and the 120-day check reruns the baseline to prove the number moved.
What one client teaches goes into configuration; what every client can use goes into the shared core. That field-to-core loop is why the next branch or site is set up rather than rebuilt.
Keep reading the guide
Start with discovery, for two weeks
The diagnostic is the Discover stage, run on one workflow, with a written plan and a fixed build price at the end.