What does the FDE role involve in the first weeks?

01Why the first weeks decide the whole engagement

A forward deployed engineer, or FDE, joins your team and works inside your codebase, your repositories, your sprint rituals and your review process. That is the point of the model: the engineer carries outside experience but delivers under your rules. It is also the risk. An engineer who arrives with a plan already in mind will often build something that looks right in isolation and wrong inside the product.

In a mature SaaS product, nothing is isolated. A new call integration touches the way calls are stored. A new AI feature touches permissions, tenant boundaries and the API client that other services already consume. If the engineer does not understand those relationships first, the work gets rewritten, or worse, it ships and quietly creates a second version of the truth.

So we treat the first weeks as a discovery phase with a deliverable, not as ramp-up time. The engineer should end that phase with a written map of the parts of the system they will touch, a list of open questions with owners, and one small merged change that proves they can move work through your process.

For a broader view of why this matters for AI work in particular, see our piece on adding AI agents to existing SaaS without rebuilding.

02What the FDE role looks like week by week

Every product is different, but the shape of a good start is consistent. This is the sequence we follow when our engineers join a client team.

1. 01

   Access and orientation.

   Repositories, environments, the issue tracker, the team chat and the review rules. The engineer reads the contribution guide and asks who approves what. Nothing gets built yet.

2. 02

   Map the data model.

   Which entities exist, how they relate, and which ones the planned work will read or write. For a communications product that means how a call, a call fragment, a recording and a practice relate to each other.

3. 03

   Trace one real flow end to end.

   Pick the flow closest to the planned work and follow it from the outside event to the stored record and the screen that shows it. This is where hidden assumptions show up.

4. 04

   Test assumptions with real behavior.

   Where third-party systems are involved, make real test calls, real API requests and real events. Compare what the documentation says with what actually arrives.

5. 05

   Write down the gaps.

   Every mismatch between documentation, existing code and observed behavior goes into a short list with a proposed owner: the client team, the vendor, or the FDE.

6. 06

   Ship one small change through review.

   A test, a validation fix or a small endpoint. The point is to learn the review process and earn trust, not to impress.

7. 07

   Agree the production path.

   Only now does the engineer propose the design for the real work, using the map and the gap list as evidence.

The order matters more than the timing. Some teams move through steps one to five in a week. Others need longer because access approvals or vendor answers take time. What should never happen is step seven before steps two to four.

03What to expect from the engineer, and what they need from you

The FDE model works when both sides know what the first weeks are for. This table is the checklist we use to set expectations with a client's engineering lead.

If the client cannot provide something in the right column, that is useful information too. A missing reviewer or a missing test account is a delay you want to see in week one, not in week six.

04How to tell whether the start is going well

Engineering leaders often ask how to judge an embedded engineer early, before there is much code to look at. These are the signals we watch.

The questions get more specific. In the first days, questions are about access and conventions. By the end of the discovery phase, they should be about edge cases: what happens when an event arrives twice, which record wins when two sources disagree, which permission check applies to a new endpoint.

The engineer reuses before they build. A good FDE looks for the existing API client, the existing validation layer and the existing cloud function pattern, and extends them. A new framework or a new service in the first month is usually a warning sign.

Assumptions are tested, not trusted. Vendor documentation is a starting point. If the engineer reports what the documentation says without having seen real events, the work is not ready to build on.

Changes are small and reviewable. Early pull requests should be easy to read and easy to revert. Large first pull requests make review hard and hide misunderstandings.

The gap list shrinks. Open questions are normal. What matters is that each one has an owner and a next step, and that the list gets shorter.

05Trade-offs to decide up front

There is a real tension in the first weeks. Your team wants visible progress, and the FDE wants enough understanding to avoid rework. Three decisions help.

Decide what counts as progress. A data model map and a tested set of assumptions are progress, even with no feature shipped. Say that explicitly so nobody feels the engineer is idle.

Decide how much discovery is enough. For a narrow change, a few days may be enough. For a new integration with an external system whose behavior is uncertain, discovery can take longer because real events must be compared before anything is trusted. Agree on a time box and on what happens when it ends.

Decide who talks to vendors. When a third-party API does not behave as documented, someone needs to open a ticket and follow it. If the FDE can do this directly, problems close faster. If only your team can, plan for that delay.

06What we see in production

Our engineers have worked inside client teams in several industries, and the pattern of a good start is the same each time.

In one placement, our engineers joined the engineering team of an established call intelligence platform for dental and veterinary practices, working under the client's processes, repositories and pull request reviews. The client led the product; our engineers delivered inside it. The first scope was a telephony integration. Before writing production code, the team mapped the existing data model and audio pipeline and studied an existing telephony integration. They then tested the provider's two subscription models side by side with real test calls, compared the event streams in notebooks and spreadsheets, and raised the gaps with the vendor's support team.

Only after that did they build the production path inside the client's own stack. It covered webhook intake, validated event models, a cloud function that turns raw call events into the product's existing call records, and an updated release of the client's API client with test coverage. Because each phone provider exposes call events differently and the vendor API changed during the work, that discovery step was what made the data trustworthy. All of it had to stay inside the product's permission model and HIPAA-aligned boundaries.

In another placement, our engineers worked inside the web team of a mobile access and digital key security company, under the client's system architect and product owner. Candidates were chosen with the architect through coding assignments and interviews, and a part-time frontend engineer started with two trial months before the commitment grew. The architect also spent time with our engineers in person to train them. Weekly goals from the architect set the order of work. One engineer documented the access token state lifecycle on his own initiative, which is exactly the kind of map a team needs before changing a system like that.

There, lock storage clearance shipped with unit and integration tests and went into the live platform one API at a time. The client's architect reported it complete, with its first API in production and running without any issue, and the work was later handed to the client's own backend team.

In a third placement, our Python engineers worked on demand alongside the client's own engineers on an established AI text-to-video product for publishers, taking tasks as the client set them. When the client asked for work outside our experience, we said so and pointed to a team that had it. Being clear about fit is part of a good start too.

07A short checklist for your first FDE conversation

Before an embedded engineer starts, agree on these points with them and with your internal lead:

• Which flows and entities the first scope touches, and who can walk the engineer through them.
• Which external systems are involved, and whether test accounts and vendor contacts exist.
• Who reviews the first pull request, and what a mergeable change looks like in your team.
• How long discovery may take before a production design is due.
• Where the data model map and gap list will live so your team keeps them after the engagement.

That last point is easy to miss. The map an FDE writes in the first weeks is often the most current description of that part of your system. Keep it in your own repository, not in the engineer's notes.

Frequently asked questions