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 (release into real use) something small and working against real data in the first week. Not a mockup and not a demo on a small, selected set of data: 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 release something tiny tells you more about the engagement than any planning document, because it makes you work with the data, the permissions and the release path all at once.
Published September 8, 2026. Editorial.
Key takeaways
- Week-one output is a scoping tool. What breaks when you release 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.
- Releasing something 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 the rest of the system comes to depend on, 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 trick to impress people. It is the cheapest test available.
What counts
Small, real, and end to end across at least one connection between systems.
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 that reads from a test file.
The distinguishing feature is working with real systems. 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 tool
Here is what releasing something tiny in week one actually shows.
The data has more errors than described. Nulls in a column documented as required, three spellings of the same category, records from a migration in 2019 with a different structure.
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 impossible to release, 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 how a project ends up late.
Learning the path to production is the most valuable result
Of everything week one produces, the most valuable is knowing how long a change takes to reach production 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 risk: shortcuts the rest of the system comes to depend on
The failure mode of releasing fast is a prototype that impresses people and cannot be made ready for production.
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 test. 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 costs of week one in a specific way.
Writing the code is no longer the limit, 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 amount of unverified code inside somebody else's production environment, and generated code is not secure by default.
So the discipline changes. 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 confirm is correct. 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 cleaned-up copy, 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 read too quickly.
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 release something so small so early?
Because it is a scoping tool. 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 releasing something. Real durations rather than published targets. This sets the schedule more than the build estimate.
What is the risk of releasing fast in week one?
That the rest of the system comes to depend on the shortcuts. A hardcoded credential, skipped error handling and ignored pagination are all fine in a week-one test, 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 writing code as the limit, so the deliverable can be larger. The risk is that a larger deliverable is a larger amount 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 set up and tested before day one, a real dataset rather than a cleaned-up copy, 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 document of the first month and the one most commonly read too quickly.
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 structure 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 released 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 unused resource in the company. 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 fail. 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 source of the information, and you cannot study 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 keeps going, 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 warning sign. The endless engagement. The demo that never becomes ready for production. 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.