FDE Engineer Role: Responsibilities from Customer Discovery to Handover

The FDE engineer role is to help turn a customer problem into a working, usable technical solution. Responsibilities can include discovery, scoping, architecture, coding, integration, testing, production rollout, adoption and handover. Some roles own the whole cycle; others focus on migration execution or deployment support. Read the exact job description and confirm who owns each decision, approval and operating task.

A customer may describe a need in one sentence: “We want to automate returns.” That sentence is not enough to build a dependable system. The engineer needs to learn what happens today, which records are trustworthy, what the software may change and who makes the final decision. The role connects those questions to code and delivery.

This article follows a fictional warehouse returns workflow to explain the responsibilities in detail. It is a learning example, not a claim about a BuildAI Careers client. For the basic meaning of the title, see what an FDE is. For preparation, use the FDE roadmap.

What does an FDE own?

Ownership means being clear about the result you are responsible for and the decisions you can make. In one team, an FDE may own the technical delivery from discovery through release. In another, a regional lead may approve scope while the engineer owns implementation and validation. Both arrangements can work if the boundaries are explicit.

Employer examples show this variation. OpenAI’s SF FDE role describes end-to-end customer deployment. Notion’s India role initially separates technical execution from regional customer ownership. Ciroos’s India role combines deployment and support. These examples were checked on 3 October 2026.

For a new engagement, write the ownership map early. Identify the user, business approver, data owner, technical reviewer and operating owner. State what the FDE decides and what needs approval. This helps the team resolve uncertainty without making unauthorised assumptions about the customer’s process.

Responsibility 1: understand the customer workflow

In the fictional warehouse, a customer requests a return, staff find the order, check the policy and create a return record. Some requests need a supervisor’s approval. The team wants less copying between tools and fewer missing fields. The FDE observes the workflow before proposing automation.

They ask staff to walk through an ordinary return and an exception. What happens when the order is missing? Which policy version applies? Who may approve the return? Which step takes time, and which step requires judgment? A normal example shows the main path; an exception reveals the boundaries.

The output is a short problem statement. For example: authorised staff need a single view of the order, relevant return policy and missing information before they prepare a request for supervisor review. This is more useful than a broad goal to “add AI” because it describes a specific user task.

Responsibility 2: agree the first version and its limits

The first version could retrieve order details, validate required fields and prepare a return request. It would not issue a refund or change inventory automatically. A supervisor remains responsible for approval. That boundary gives the engineer a useful workflow to build without taking on every possible return action.

Write the included and deferred work. Included: order lookup, policy display, field validation and review submission. Deferred: automatic refunds, inventory adjustments and complex exceptions. Explain the reason for a deferral when it affects the user: a payment integration or approval rule may need separate work.

The FDE should obtain the relevant agreement before implementing a materially different scope. If the customer later asks for automatic approval, the team revisits permissions, policy rules and tests. A scope change is a decision to assess, with consequences for time and responsibility.

Responsibility 3: define successful delivery

Acceptance criteria turn the scope into checks. An authorised staff member can find an eligible order and prepare a valid return request. An invalid request shows the missing field. A request outside the approved policy routes to review. A staff member cannot issue a refund through the first version.

Define the workflow measure as well. The team might observe the time taken to prepare a request and the number of requests returned for missing fields. Establish how the baseline and pilot will be measured before promising an improvement. In this fictional example, no outcome figure has been measured.

Keep acceptance and business outcomes distinct. Passing a test shows the application meets a defined case. A pilot observation shows how the workflow behaves with users. Both are useful, but they answer different questions. The FDE should make the distinction clear when reporting progress.

Responsibility 4: choose an architecture that fits

The warehouse tool might have a simple web interface, an API service and connections to order and policy data. The service validates requests and stores their review status. A supervisor uses the interface to inspect prepared requests. The architecture should be small enough to explain and sufficient for the agreed scope.

The FDE identifies assumptions and dependencies. Is the order API available? How are staff identities established? Where is the current policy stored? What happens if the lookup service fails? These questions guide the design. Choosing a fashionable framework before answering them can create avoidable work.

Document a few consequential decisions. Explain why the tool prepares a request rather than issuing a refund, why policy versions are stored and why the application keeps an audit record. A short decision note helps later reviewers understand the design and prevents the same debate from restarting without new evidence.

Responsibility 5: connect data and external systems

Map the fields the workflow needs: order identifier, customer reference, item, purchase date and return reason. Identify which system supplies each field. Check how missing, inconsistent or outdated values are handled. The interface should not make a record appear complete just because the lookup returned a successful status.

Define the API contracts. The order lookup may return no match, several possible matches or a temporary error. The return-record endpoint may reject a duplicate or an invalid field. The FDE needs to implement the expected behaviours and give the user a clear next action.

Plan safe retries. If creating a return request times out, the application should know whether the request already exists before creating another. An agreed identifier can help recognise a repeated action. Test this behaviour with the dependency under controlled failure conditions instead of assuming a retry loop is safe.

Responsibility 6: enforce permissions and action boundaries

Different people may have different permissions. Staff can prepare requests; supervisors can approve them. The first version cannot issue refunds. These rules belong in the application’s enforced behaviour. A hidden button or a prompt saying “do not refund” is insufficient if an API still accepts the action.

Use fictional test identities to check the boundary. Try reading another customer’s restricted order and submitting an approval as an ordinary staff member. The test should fail for the right reason. Check the backend response and stored result, not only what the interface displays.

The FDE also needs the customer’s approval for the data and systems used in the engagement. When a dependency or permission is unavailable, report the blocked step and a concrete option. Do not silently replace a required control or use data outside the agreed boundary to keep the demo moving.

Responsibility 7: implement and review the solution

Build the main journey in small changes. Start with order lookup, then add validation and review submission. Run the relevant checks after each change. Small steps make it easier to connect a failure to the code that introduced it and to review whether the implementation still matches the scope.

Code review should check more than style. Does validation happen before writing data? Can an invalid state be stored? Does the error message help the user? Are secrets kept out of the source? The FDE should be able to explain the result and correct the issues identified.

An AI coding assistant can contribute suggestions, but the engineer remains responsible for accepting and testing them. Review generated changes in the context of the whole application. A helper that works in isolation may conflict with authentication, retry behaviour or the actual data model.

Responsibility 8: evaluate AI features when they are included

The warehouse may ask for a draft explanation of the return policy. The FDE can retrieve the relevant approved policy and generate text for staff review. The feature should distinguish the current version from an older document and avoid making a decision unsupported by the policy.

Create evaluation cases before expanding the feature. Include a routine request, an ambiguous purchase date, missing policy evidence and a request for an exception. Define what the application should show in each case. Check both source retrieval and generated text because either stage can produce a misleading result.

Keep actions separate from text. A generated draft explanation does not authorise a refund or approval. The application should enforce the permitted workflow independently. If the team later considers broader automation, it needs a fresh scope and a testable approval design.

Responsibility 9: test the complete journey

A component test can check a validation function. An integration test can check the order lookup contract. A user journey can check that an authorised staff member prepares a request and a supervisor sees it. Each type contributes evidence, but the complete workflow needs its own checks.

Test failure paths deliberately. Stop the simulated order service, return an incomplete payload and repeat a submission. Verify the user message and the stored data. A test should detect the problem it is designed for; if removing the control still leaves the test passing, improve the assertion.

Use test data and intercepted or simulated consequential actions. For a returns exercise, do not create real refunds or modify customer inventory to prove a synthetic test. Label the environment and scope. The engineer should report what was tested and avoid claiming effects that were never exercised.

Responsibility 10: plan and verify rollout

Begin with a controlled release to a small group of intended users. Confirm the version, configuration and access. Run the agreed journeys in that environment and inspect the results. Keep the earlier process available where the plan requires it so users have a way to complete their task if the new tool fails.

State the rollout decision. Who approves expansion? Which failure would pause the pilot? What is the rollback route? If the release changes data, check how recovery works. A rollback plan should account for the actual system instead of assuming that reverting code reverses every effect.

Record the verified outcome. Separate deployed, journey-tested and adopted states. A successful deployment means the release reached the environment; it does not automatically prove users completed the workflow or that the business measure improved. The FDE should keep these observations precise.

Responsibility 11: make the system operable

Write a runbook for the operating team. Explain how to recognise lookup failures, investigate a duplicate and check a request’s status. Include the relevant logs, safe recovery steps and escalation owner. Use terms the operator understands and link to deeper technical detail where useful.

Document configuration and ownership. Who can update the policy source? Who approves permission changes? Who maintains the integration when the order system changes? Handover should resolve these questions before the FDE moves to another engagement.

Ask an operator to follow the instructions during a review. If they need you to explain an undocumented step, improve the runbook. This checks whether the work is transferable. A polished demo can hide a system that only its original engineer knows how to run.

Responsibility 12: turn delivery lessons into reusable work

The returns engagement may reveal a validation or audit component that another customer could use. The FDE can separate the reusable logic from customer configuration and describe its assumptions. Reuse should reduce repeated work without carrying one customer’s private details into another environment.

Report repeated platform gaps with evidence. If several workflows need the same approval behaviour, describe the requirement, workaround and operational cost. The product team can assess whether to build a shared feature. Concrete examples are easier to evaluate than a general request for “more flexibility”.

Keep the feedback connected to what was observed. Explain which users encountered the issue and how the team confirmed it. Distinguish a single customer preference from a repeated need. This helps engineering prioritise a change without overstating the evidence.

A practical ownership map for the fictional project

Use a map like this to ask questions, then adapt it to the real organisation. Titles and approval routes will differ. The purpose is to avoid a task being treated as complete when the person responsible for its next step has never accepted it.

How should an FDE handle a new request during delivery?

Halfway through the fictional build, the customer asks to approve low-value returns automatically. The engineer should clarify the rule and its consequences. Which value is used? Are there product exceptions? Can a customer make several small requests that together exceed the intended limit? Who can revise the threshold?

The FDE then explains the options. One option keeps supervisor review for the current release and studies automation later. Another adds a narrowly defined approval rule after the relevant permissions and tests are agreed. The customer can compare the extra work and risk. The engineer should update scope and acceptance criteria if the change is approved.

This is where technical and customer responsibility meet. Saying yes without checking the rules can produce a fragile system. Saying no without an explanation can block a useful improvement. A clear assessment gives the customer a decision they can make and the engineering team a requirement they can test.

How should an FDE report a blocked dependency?

Suppose the order API credentials are not available. The engineer can continue with a simulated contract while making the dependency visible. They should explain which parts are verified against the simulator and which still need the real environment. The simulation can support development, but it cannot establish that the live integration works.

A useful update names the blocked step, its effect and the next action. For example: “The review interface is ready for testing with fictional orders. Live order lookup still requires the customer-approved API access. Once access is available, we will verify field mapping and failure responses before rollout.” The wording helps the owner resolve the dependency.

Keep the evidence current when the dependency is resolved. Test the real contract, inspect differences and update the design if needed. A saved note saying that a simulator passed should not become a claim that the production integration passed. Precise status is part of the engineer’s responsibility.

What should the engineer establish in the first week?

Confirm the user problem, ownership map, permitted data, initial scope and access dependencies. Obtain enough sample information to assess feasibility without collecting more than the project needs. Agree how decisions and changes will be recorded. Identify the first review point and the evidence it requires. These practical steps give the team a shared starting point and make later progress easier to evaluate.

How does the work change across a project?

Use the project stage to decide what evidence a status update needs. During discovery, show the agreed brief and remaining questions. During implementation, show the working journey and tests. During rollout, show the environment, version and verified cases. During handover, show the runbook review and operating owner. Each stage has a different completion condition.

This also helps when a project changes hands. The next engineer can find the current scope, implemented behaviour and unresolved dependency without reconstructing every conversation. A compact record of decisions and evidence supports continuity while keeping the customer’s workflow and approved boundaries visible.

Early work may involve interviews, samples and design decisions. During implementation, coding and integration take more time. Before release, testing and approval become central. After launch, the engineer may focus on adoption, incidents and handover. The balance changes with the stage and the team’s operating model.

Ask about that balance when considering a job. Some teams assign several engagements at once; others give an engineer a focused workstream. Some include ongoing support; others have a separate operating team. The day-to-day FDE article adds another perspective on how these tasks can appear in practice.

How to show these responsibilities in an interview

Keep a short record of a decision that changed the project. It might show how a customer question narrowed the scope or how a failed test changed the design. Include the original assumption, observed evidence and final action. This gives your explanation a specific event the interviewer can examine.

Choose one project and explain the full chain of decisions. Start with the user problem, then describe scope, design, implementation and tests. Show a failure and the correction. Finish with release and handover. This lets the interviewer ask about your judgment at each stage.

Be precise about your role. You may have implemented a component while another person owned discovery. That is useful evidence when described accurately. If the example is a learning project, explain the fictional context and what you personally built. Use the worked interview guide for practice.

Frequently asked questions about the FDE role

Does an FDE own every stage?

Some roles do; others divide discovery, technical execution and customer acceptance across a team. Confirm the ownership map for the vacancy.

How much coding is involved?

It varies. Read the programming and implementation responsibilities and ask what a typical workstream involves.

Does the role include customer meetings?

Many roles involve direct collaboration, but some initially focus on internal execution. Check the employer’s description and expected progression.

Who operates the system after delivery?

The FDE, a customer team or another support team may own operation. Agree the boundary and handover before launch.

How is success measured?

Use agreed acceptance checks and relevant workflow observations. Separate deployment, correct behaviour, adoption and measured business results.

How can I practise the role?

Build a small fictional workflow through discovery, code, tests, deployment and handover, then obtain feedback on the complete result.

Practise the delivery cycle

Review FDE training in India to explore the curriculum and project work. FDE training in India or talk to a course advisor on WhatsApp.

Sources and review date

Employer role examples checked on 3 October 2026. The warehouse scenario, responsibilities walkthrough and ownership map are original instructional examples.

1. OpenAI: SF FDE role.
2. Notion: India FDE role.
3. Ciroos: India FDE role.