This document lays out the first 90 days of a forward deployed engineer inside your codebase, written from the client's side: five phases, what you receive and what you provide in each, and six signs the engagement is drifting. Use the day 30, 60 and 90 checkpoints as the contract.
1. Two published descriptions of how the role actually works
Two published accounts describe the same 90 days from opposite chairs: one from the team that sends the engineer, one from the engineer.
From the team that sends the engineer. The Pragmatic Engineer's deep dive of August 12, 2025 describes how one AI lab's forward deployed engineering team works with a customer, in three phases.
Scoping: a couple of days onsite, sitting with users, mapping their processes, finding the biggest value areas, prototyping with synthetic data.
Validation: the team returns to answer one question, whether what was scoped is the most valuable thing they can do. Then it agrees on validation criteria, builds quality checks from user input, and reports results against the objectives.
Delivery: onsite a few days per week, the exact details of the problem, real data, solutions built and demonstrated, always "the smallest unit possible" that works end to end.
The head of that team explains why validation comes before delivery: what the customer describes in scoping often does not match the data and the systems on the ground, so the team moves fast, finds the walls and adjusts the scope.
From the engineer. Vinoo Ganesh built the program that trained more than 250 engineers into the role at the company that created it, from 2015. His guide of February 5, 2026 gives the engineer's 90 days.
Days 1 to 30: learn. Absorb context, meet everyone, read all documentation, shadow every call, do not try to add value yet.
Days 31 to 60: find the first win. One small thing owned completely, with a clear before and after, shipped and announced.
Days 61 to 90: start forming opinions. Engage harder problems, propose solutions.
He names four traps: overengineering, retreating into code when a meeting gets tense, overpromising, and solving the wrong problem. His most important question for the role: "what are you trying to accomplish?"
What the two agree on. The order (understand, prove, deliver) and the failure mode (building before understanding). What neither gives is the view from the buyer's chair. That is the rest of this document.
2. The plan from the client's side
| Phase | Days | What the engineer does | What you receive | What you provide |
|---|---|---|---|---|
| Discovery | 1 to 15 | Sits with the people who live the problem, reads the code and the systems, maps the process as it runs today, asks "what are you trying to accomplish?" until the answer is a measurable result | A discovery memo: the problem in one paragraph, the observable result that will define done, the systems and data involved, the constraints found (access, security, data quality), and the risks | Access to the repository, the systems and the people; one named owner on your side who can decide |
| Specification | 10 to 25 | Writes the spec with your team: behavior, interfaces, acceptance criteria that a test can check, what is out of scope | The spec, in your repository, reviewed and approved by your owner; a validation plan stating how you will both know it works before it is finished | Review within two working days; the decision on what is out of scope |
| Validation | 20 to 40 | Proves the risky part first: the integration nobody has done, the data nobody has looked at, the model behavior nobody has measured. Builds the checks that will define quality | A working slice of the hardest part against real data (a prototype, not production code), and the quality checks that the final system will have to pass; if the slice fails, a revised scope with the reason | Real data, in the environment where the system will run; a decision if the scope has to move |
| Build | 35 to 75 | Directs and reviews the agents that write the code; every change passes tests, types, linters, structural checks and a review rubric before a person is assigned; ships the smallest unit that works end to end, then the next | Increments in production, each behind your gates, each demonstrated on your data; the pipeline that enforces those gates, in your CI | Reviews by exception (architecture, security boundaries, blast radius) and the go ahead for each increment |
| Operate and transfer | 60 to 90 | Runs the system in production, handles the first incident, writes the operating handbook, pairs with the people who will own it | The system in production with its handbook, its runbook for incidents, its tests in your CI, and a named person on your team who has operated it with the engineer beside them | The person who will own it, with time reserved to pair |
3. Deliverables that should exist by day 30, 60 and 90
Day 30: the discovery memo and the spec, both in your repository, both approved by your owner. A first meeting with your security or infrastructure person has happened. A one page description of your system, written by the engineer and approved by your CTO, exists. Nothing has been built for production yet, and that is correct. If any of this is missing: nothing gets built until it exists.
Day 60: the hardest part of the problem works against real data, with the quality checks written. At least one increment is in production behind your gates. The pipeline that enforces the gates exists in your CI and rejects a change that fails them. Your team has reviewed agent written code by exception and knows what the exceptions are. If any of this is missing: no further increment goes in until the gates exist in your CI and have rejected a change.
Day 90: the system is in production and has survived its first incident or its first month, whichever came first. The operating handbook and the incident runbook exist. Someone on your team has run it with the engineer beside them and can run it alone. The spec, the tests and the pipeline stay in your repository whether or not the engagement continues. If any of this is missing: the engagement does not close until the named person has run the system alone.
4. Six signs the engagement is drifting
- Day 15 and there is no discovery memo, or the memo describes a solution instead of a result. The engineer is building before understanding.
- The spec is a document only the engineer has read. Your owner has not approved it, and acceptance criteria cannot be turned into tests.
- The first thing built is the easy part. Validation exists to find the walls early; if the risky integration is scheduled for day 70, the plan is backwards.
- Increments are demonstrated on synthetic data after day 40. Real data is where scoping breaks; untouched data means an untested scope.
- Code reaches production without passing through gates in your CI. If the checks live on the engineer's machine, they leave with the engineer.
- Day 75 and nobody on your team has operated the system. Transfer is a phase with time reserved, not a handover meeting on the last day.
5. How we run this on our own engagements
On our own work, in SaaS companies and IT departments alike, discovery ends when the observable result is written in one sentence the client's owner has approved. The spec lives in the client's repository from the first draft. Validation takes the part with the most unknowns first, on the client's real data, and it has changed the scope of several engagements early, when it was still cheap. The agents that write the code do not open a pull request until every automated check passes; the client's reviewers read what needs a human. Transfer starts by day 60 with a named person pairing on real operation, to avoid the failure Ganesh names: a system only its author understands.
6. How to use this document
Before signing, ask the provider to fill in the "what you receive" column with dates. If the answer for day 30 is production code, or the answer for day 90 does not include a named person on your team operating the system, you are buying development hours with a new title.
Questions and answers
What should exist on day 30 of a forward deployed engagement?
A discovery memo and a specification, both in your repository and approved by your owner. A first meeting with your security or infrastructure person has happened, and a one page description of your system is approved by your CTO. Nothing has been built for production yet, and that is correct at this point.
What does the client have to provide?
Access to the repository, systems and the people who live the problem; reviews within two working days; the decision on what is out of scope; real data in the environment where it lives; reviews by exception on architecture and security; and the person who will own the system, with time reserved to pair.
What is the earliest sign that an engagement is going wrong?
Day 15 with no discovery memo, or a memo that describes a solution instead of a result. It means the engineer is building before understanding the problem. Other early signs: a specification only the engineer has read, and the easy part being built first while the risky integration waits.
When should the engagement close?
Not before a named person on your team has run the system alone. By day 90 the system is in production and has survived its first incident or its first month, the handbook and incident runbook exist, and the specification, tests and pipeline stay in your repository whatever happens next.
Sources
- The Pragmatic Engineer (Gergely Orosz), What are Forward Deployed Engineers, and why are they so in demand?, August 12, 2025. https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers
- Vinoo Ganesh, The Definitive Guide to Forward Deployed Engineering, February 5, 2026. https://nextplayso.substack.com/p/the-definitive-guide-to-forward-deployed
Analysis and conclusions by yaab, based on the published reports listed above.