Forward Deployed Engineer vs In-House Hire vs Agency
You need an AI or data system running in a real customer environment, not a demo. There are three ways to staff that work. Each is right for a different situation, and picking the wrong one costs months.
By the TARDIS Solutions engineering team · Updated
The short answer
| In-house hire | Agency / outsourcing | Forward deployed engineer | |
|---|---|---|---|
| Time to first useful work | 3-6 months (search, notice, onboarding) | 2-6 weeks (contract, discovery) | 1-2 weeks |
| Who owns the outcome | You | The statement of work | Shared: the FDE owns getting it live |
| Works inside your repos and customer sites | Yes | Usually not; delivers artefacts | Yes |
| Context retained after the project | Fully | Little | Written down in runbooks and decision logs |
| Best for | Permanent, core capability | Well-specified, separable builds | Messy deployments with a deadline |
| Main risk | Slow to start, hard to undo a bad hire | Spec gaps become change requests | Needs real access and a clear owner on your side |
When an in-house hire is the right call
If the work is your core product and will exist for years, hire. An employee accumulates context no outsider can match, and you are building a team, not buying a deliverable. The catch is time: a senior AI or geospatial engineer in India typically takes two to four months to find, then serves a notice period, then needs a quarter to become fully productive. If the deployment has a date on it, a hire alone will not meet it.
- The capability is permanent and central to what you sell.
- You have someone senior who can interview and manage the hire well.
- The deadline is at least six months away.
When an agency is the right call
Agencies are good at well-specified, separable builds: a marketing site, a mobile app against a stable API, a dashboard with clear requirements. They are structurally weak where the work is ambiguous and lives inside someone else's environment, because every ambiguity becomes a change request and nobody on their side is accountable for the system actually running at the customer.
- The scope can be written down completely before work starts.
- The output is an artefact you take over, not a system that must be operated in place.
- Price certainty matters more than adaptability.
When a forward deployed engineer is the right call
The forward deployed model, made famous by Palantir, exists for the gap between a working product and a working deployment. An FDE sits with your team, has access to your repositories and your customer's environment, and is measured on the system being live and used. They handle the parts nobody specified: data that doesn't match the schema, networks that block the obvious approach, security teams that need everything on-prem, and customers who change their minds.
- An AI pilot works in a demo and stalls on the way to production.
- An enterprise customer needs your product in their VPC, on-prem or air-gapped.
- Integration work for new customers keeps pulling your core engineers off the roadmap.
- You are hiring for the role but the deployment can't wait for the hire.
Cost: compare total cost, not day rates
Day rates mislead. An in-house hire's real cost includes recruiting fees, the months before they are productive and the management time they need. An agency's real cost includes the change requests that follow every unspecified detail. An FDE engagement is usually priced as a monthly retainer or a fixed push, and its real cost is the access and decision-making time it needs from your side. The fair comparison is: what does it cost to have this system live by the date that matters, and who carries the risk if it slips?
A common pattern that works: bring in an FDE to get the first deployments live and write everything down, while you hire. The FDE's runbooks and decision logs become the new hire's onboarding.
Questions to ask any option
- Who, by name, is accountable for the system being live at the customer?
- Will the work happen in our repositories, under our accounts, from day one?
- What will exist after you leave: runbooks, architecture notes, a recorded walkthrough?
- Have you deployed into environments like ours (on-prem, regulated, air-gapped)?
- What do you need from us each week, and what happens when we're slow to provide it?
Frequently asked questions
Is a forward deployed engineer just an expensive contractor?
No. A contractor executes tickets someone else wrote. An FDE owns an outcome, a system live in a real environment, and does the unglamorous work around it: customer IT, data cleanup, deployment, documentation and hand-over.
Can we start with an FDE and hire later?
Yes, and it is often the best sequence. The FDE gets the first deployments live and documents them; the permanent hire inherits a working system and a written record of every decision.
Do FDEs work remotely?
Mostly, with an agreed overlap window and travel for critical go-lives where needed. What matters is real access to the environments, not physical presence.