Forward deployed engineering: the complete guide / How an engagement runs
What a forward deployed engineer ships in week one
A forward deployed engineer should ship something small and working against real data in the first week. Not a mockup and not a demo on a curated slice: one transform, one screen reading live records, one integration returning a real response. The point is diagnostic rather than promotional. What breaks when you try to ship something tiny tells you more about the engagement than any planning document, because it forces contact with the data, the permissions and the release path all at once.
Key takeaways
- Week-one output is a scoping instrument. What breaks when you ship something small is the real scope, discovered in days instead of months.
- It has to touch real data, real authentication and the real release path, or it has tested nothing.
- Shipping small early is also how you find out how long a change actually takes to reach production at this company.
- The failure mode is a prototype whose shortcuts become load-bearing, which produces an impressive demo and a late production date.
The norm in this model is that something works in week one. It sounds like a stunt. It is the cheapest diagnostic available.
What counts
Small, real, and end to end through at least one seam.
Good week-one deliverables: one data transform running on production data, one screen that reads live records, one integration that calls the real third-party API and handles its real error, one alert that fires on a real condition.
Not week-one deliverables: a wireframe, a slide describing the architecture, a script that works on a CSV somebody exported by hand, a demo pointed at a fixture file.
The distinguishing feature is contact with reality. A thing that works on exported data has tested your code. A thing that works on live data has tested your code, the schema, the permissions, the network path, and the assumption that the field called status means what somebody said it means.
Why it is a scoping instrument
Here is what shipping something tiny in week one actually surfaces.
The data is dirtier than described. Nulls in a column documented as required, three spellings of the same category, records from a migration in 2019 with a different shape.
The permission model does not match the business. The business treats two roles as different and the system models them as one, or the reverse. This is one of the most common causes of an AI feature being unshippable, which is why we wrote separately about permissions being the hardest part.
The API behaves differently under real conditions. Rate limits, intermittent timeouts, a payload that includes a field the documentation omits.
The release path is longer than anybody said. You will find out that a change needs a security review, that the review board meets fortnightly, and that the next meeting is in nine days.
Each of those is a scope item. Finding four of them in week one and re-planning is a good week. Finding them in month three is the story of a late project.
The production-path discovery is the real prize
Of everything week one produces, the most valuable is knowing how long a change takes to get live at this specific company.
Ask in week one, then verify it by doing it. What must be true for a change to reach production, who signs each step, and how long each signature historically took. Published targets are not the answer you want. Real durations are.
This number sets the schedule more than the build estimate does, and it is the number most engagements discover too late. How an engagement runs covers where it fits.
The trap: shortcuts that become load-bearing
The failure mode of shipping fast is a prototype that impresses people and cannot be hardened.
It happens like this. To get something working in week one you hardcode a credential, skip the error handling, ignore the pagination, and query production directly. All correct decisions for a week-one probe. Then somebody senior sees the demo, the demo becomes the plan, and the shortcuts are now in the critical path.
Two habits prevent it. Say out loud, in writing, what the week-one thing fakes. And keep it small enough that throwing it away costs a day, because the option to discard it is what stops it becoming the architecture.
What this looks like when a model writes the code
On our engagements the code is AI-written, which changes the arithmetic of week one in a specific way.
The typing is no longer the constraint, so a week-one deliverable can be larger than it used to be. The risk is that a larger week-one deliverable is a larger pile of unverified code inside somebody else's production environment, and generated code is not secure by default.
So the discipline moves. The eval suite comes from the specification before the code exists, and the week-one deliverable has to pass it like anything else. That keeps the speed and it stops week one from producing something nobody can vouch for. Eval-driven development is the method, and never letting the model grade its own work is the part that makes it mean anything.
For the customer: what to expect and what to provide
Expect the week-one thing to be unimpressive and informative. Its value is the list of surprises attached to it, not the thing itself.
Provide access before day one, a real dataset rather than a sanitised extract, and a named person who can answer a question the same day. The first two weeks has the full checklist.
And read the list of surprises when it arrives. That document is the most useful thing you will get in the first month, and the most commonly skimmed.
Common questions
What should a forward deployed engineer deliver in the first week?
Something small and working against real data: one transform running on production data, one screen reading live records, or one integration calling the real API and handling its real error. Not a wireframe, an architecture slide, or a script that works on a hand-exported CSV.
Why ship something so small so early?
Because it is a scoping instrument. Touching live data tests the schema, the permissions, the network path and the assumption that a field means what somebody said it means. Finding four surprises in week one and re-planning is a good week; finding them in month three is a late project.
What is the most valuable thing week one produces?
Knowing how long a change actually takes to reach production at that specific company. Ask what must be true, who signs each step, and how long each signature historically took, then verify it by shipping. Real durations rather than published targets. This sets the schedule more than the build estimate.
What is the risk of shipping fast in week one?
That the shortcuts become load-bearing. A hardcoded credential, skipped error handling and ignored pagination are all fine in a week-one probe, until somebody senior sees the demo and the demo becomes the plan. Write down what the thing fakes, and keep it small enough that discarding it costs a day.
Does AI-generated code change what week one should look like?
It removes typing as the constraint, so the deliverable can be larger. The risk is that a larger deliverable is a larger pile of unverified code inside somebody else's production environment. The discipline is that the eval suite comes from the specification before the code exists, and week one passes it like anything else.
What does the customer need to provide for week one to work?
Access provisioned and tested before day one, a real dataset rather than a sanitised extract, and a named person who can answer a question the same day. Then read the list of surprises the week produces, which is the most useful and most commonly skimmed document of the first month.
Related reading
Why permissions are the hardest part of an AI feature
A normal feature shows one user one screen. An AI feature reads across everything it can reach and writes a summary, and a summary has no permission model.
Why your staging environment is lying to you
Staging passed. Production broke. That is not bad luck, it is a predictable consequence of the five ways staging differs from the place your users actually are.
More in How an engagement runs
How a forward deployed engagement runs
A forward deployed engagement runs in five phases: discovery inside the environment, a prototype against real data, deployment to production, productizing what turned out to be reusable, and scaling back so the customer's own team runs it. The first three are what everyone plans. The fourth is what turns one customer's work into a product. The fifth is the one that gets skipped, and skipping it is the difference between a deployment and a dependency. AWS describes a similar three-phase shape for its partner programme, ending with the partner working independently.
The first two weeks of a forward deployed engagement
The first two weeks decide the pace of everything after them. By day ten a working engagement has shipped something small against real data, written down what correct means, and mapped the path a change takes to production. The most common way to lose those two weeks is access: an engineer waiting on repository credentials is the most expensive idle resource in the building. Three things have to exist before day one, and all three are the customer's to provide.
Discovery inside the customer environment
A discovery call gives you what the customer can describe. Being inside the environment gives you what nobody thought to mention, and that second category is where deployments break. Marty Cagan's argument for the embedded model is that it is a product discovery technique rather than a delivery technique: engineers who visit multiple customer sites see the similarities and differences across a market, which is the essence of customer discovery. The practical version is that the environment is the instrument, and you cannot read it from outside.
Handover and exit from a forward deployed engagement
The ending of a forward deployed engagement has to be designed at the start, with a date in the contract at signature. An engagement whose conclusion is decided later does not have one: it drifts, because there is always one more improvement and both sides find the arrangement comfortable. AWS named customer self-sufficiency after the engagement as a design goal of its own programme, and its partner model ends with the partner team working independently. The test of a handover is not whether documents were delivered. It is whether the customer's own engineer has changed the system, alone, before the vendor left.
What goes wrong in forward deployed engagements
Forward deployed engagements fail in a small number of recognisable ways, and most of them are visible by week three if you know the tell. The endless engagement. The demo that never hardens. The engineer who became an account manager. The bespoke fork nobody can upgrade. The pilot that was never going to production. And the handover that was a slide deck. Each has an early signal and a specific intervention, and none of them get fixed by the engineer working harder.