SERVICE · FORWARD DEPLOYED ENGINEERING (FDE)
An engineer inside your workflow, from scope to launch
Tenten works with the people doing the job to define the problem, connect systems and test exceptions. Start with one workflow, a named owner and clear acceptance criteria, with handover and operating responsibility agreed upfront.
لخّص هذه الصفحة بالذكاء الاصطناعي
DEFINITION · WHAT IS AN FDE
What is an FDE?
A Forward Deployed Engineer (FDE) works inside a client’s team and systems. With the workflow owner, they define the scope, build and test the system, take it into production, then hand over the agreed code, documentation and operating knowledge.
Forward deployed means close to the work: understanding how users decide, where data comes from, and how permissions and exceptions work. On-site arrangements depend on the engagement. What matters is direct involvement in delivery and access to the people who own the decisions.
Palantir popularized this model. Since 2025, AI model companies including OpenAI and Anthropic have also built forward-deployed teams to help customers put models into practical use. Roles and engagement terms vary, so review deliverables, responsibility and exit conditions for each provider.
COMPARISON
How does FDE compare with the alternatives?
Do you need direction, integration, lasting internal capability or a ready-made tool? A job title cannot replace a delivery agreement. Each approach has a useful role.
On smaller screens, scroll horizontally to compare every approach.
| What to compare | FDE | Traditional consultant | Systems integrator (SI) | In-house team | Buy SaaS directly |
|---|---|---|---|---|---|
| Who works with you | Engineers build with the workflow owner | Advisors interview and analyze; implementation depends on scope | Integration team coordinates with IT and vendors | Internal engineers and business teams | Internal administrator with vendor support |
| What is delivered | A live workflow and agreed handover materials | Strategy, diagnosis and decision support | Agreed systems, interfaces and integration acceptance | Ongoing development and operating capability | Existing product features and service support |
| Time to first launch | Depends on the first workflow, data and approvals | Advice can come first; launch requires an implementation plan | Depends on integration scope and vendor coordination | Depends on capacity, hiring and priorities | A matching product can be trialed first; assess integration separately |
| Where knowledge stays | Agreed code, evaluations, documentation and team handover | Reports and workshops; confirm implementation knowledge transfer | Design and runbooks; confirm licensing | Internal code, documentation and people | Product stays with the vendor; check configuration and data portability |
| Best fit | A defined workflow needing joint implementation and integration | Direction or organizational decisions need alignment | Standard integration or replacement across enterprise systems | Core capability requiring continuous development | A mature product already meets the need |
| Main risk | Scope growth, external-engineer dependency and incomplete handover | No owner between advice and implementation | Vendor dependencies and unclear acceptance boundaries | Hiring, management and key-person turnover | Feature limits, data portability and vendor dependency |
FIT
Does this workflow need an FDE?
A useful fit
- A repeated bottleneck with an owner who can make decisions
- AI needs to connect to existing systems and ready-made tools leave a gap
- Approved data and access are available, with users ready to test
- Your team can review the work and prepare for handover or agreed operations
- You want to assess expansion using working software and real cases
Consider another approach first
- No workflow owner or agreement across the teams involved
- You only need a one-off report, presentation or tool training
- A mature SaaS product covers the need through configuration
- Data or permissions are unavailable but production launch is expected
- Your core product needs continuous development and you already have the capacity
HOW TENTEN WORKS
Evaluate → Build → Run
Each phase states deliverables, responsibilities and stop conditions. Use evidence from the first workflow to decide what comes next.
EVALUATE
Define one workflow
Confirm users, data, permissions, key risks and acceptance criteria. Recommend whether to proceed, prepare or stop.
BUILD
Build and review together
Connect agreed systems and use real cases to test the main path, exceptions and human handoff. Give the team working software to review.
RUN
Launch with responsibility
Confirm monitoring, incident handling, regression evaluation and runbooks. Assess handover or expansion after acceptance criteria are met.
People + platform: build together, review the same evidence
Engineers own the implementation. The delivery workspace gives your team a shared record of scope, progress, evaluations and decisions. Required records and their maintenance are agreed as part of the engagement.
See the delivery workspaceCOST & HANDOVER
Can an FDE engagement become a cost trap?
Yes, if requirements keep growing or only the external engineers understand the system. Build costs include engineers working with your team. Model, infrastructure and operating costs continue after handover and should be stated separately in the proposal.
- Bound the work
- Agree on one workflow, interfaces, acceptance criteria, assumptions and exclusions. Assess new requests before changing the scope.
- Specify the handover
- Agree on code, prompts, architecture documentation, evaluation sets and results, runbooks, and training for operation and exceptions. Confirm ownership, third-party licenses and data portability individually.
- Specify when to stop
- Review stop conditions if data or access is missing, benefits no longer justify the work, or the first workflow has passed acceptance and handover. Continued operations or another workflow needs a separate scope decision.
RELATED
Explore your workflow in more detail
Forward Deployed Marketing (FDM)
Apply the same delivery approach to marketing data, tools and review workflows.
Public work
Review published delivery evidence before discussing an engagement.
Agentic workflows
Connect routine tasks with human approvals, exception handling and execution records.
RAG knowledge systems
Retrieve internal documents with sources, versions and permissions you can check.
FAQ
Questions about forward deployed engineering
What is an FDE, and how does the role differ from other engineers?
An FDE works inside a client’s team and systems. Alongside coding, they define requirements with the workflow owner, handle integration, test real cases and plan handover. Specific skills and responsibilities depend on the engagement.
How is an FDE different from a consultant?
Consultants help with direction, diagnosis and organizational decisions. FDE focuses on implementation with the team, taking an agreed workflow into production. Some consultancies also implement systems, so compare deliverables and responsibility directly.
Does a forward deployed engineer have to work on-site?
No. On-site work depends on the workflow, collaboration and security requirements. The engineer needs access to the actual work and approved systems, plus review with decision-makers and users.
How long does the first workflow take to launch?
Timing depends on data access, interfaces, approvals and acceptance conditions. We review constraints and dependencies before agreeing on a timeline in the proposal. The FDE label alone cannot promise speed.
Can our internal team take over when the engagement ends?
Agree upfront on code access, prompts, documentation, evaluations, training and operating responsibility. Third-party licensing, ownership and exit terms belong in the contract so your team can assess handover conditions.
How are data and security handled?
Before connecting data, we review deployment, access, model-provider terms, retention and training policies with your IT and security teams. We build with approved sources and test both allowed and denied access.
Do we need an FDE if we already have an SI or internal engineers?
Start with the gap. If your existing team can deliver the workflow, integration and operations, an FDE may be unnecessary. Where implementation or collaboration needs support, agree on specific responsibilities to avoid duplication.
When should the engagement stop?
Review stop conditions when data or approvals cannot be obtained, expected benefits are insufficient, or acceptance and handover are complete. Continued operations and expansion need their own agreement, with established facts, artifacts and remaining risks documented.
Start with the workflow that is stuck
Bring the current steps, systems, owner and common exceptions. We will assess whether a build makes sense and which prerequisites are still missing.
Bring us one stuck workflow