The Part Nobody Wants To Admit About Outsourcing
I've been running engineering delivery for over two decades. In that time I've seen every flavour of the offshore-onshore debate, and I'll say the quiet part out loud: the reason most outsourced software projects underperform has almost nothing to do with the engineers' skill. It has everything to do with the distance - physical, organisational and contextual - between the people writing the code and the people who actually understand the problem.
Enter the Forward Deployed Engineer
A Forward Deployed Engineer, or FDE, is a senior engineer who sits with the client - in their office, in their standups, in their hallway conversations - and is backed by a full delivery team somewhere else. In our case, that somewhere else is our engineering centres in Bengaluru and Kochi. The FDE is not a business analyst with a laptop. They can read your codebase, ship a pull request, argue with your architects and translate a whiteboard sketch into a working service by the end of the week.
The model isn't new - Palantir popularised the label, and elite consultancies have quietly worked this way for years. What's new is that in 2026 it has become the *right default* for a much wider class of projects, not just the top 1% of engagements. Two things caused that shift:
- ▹AI has collapsed the cost of writing code, but not the cost of understanding a business. A team can now produce a plausible first version of almost anything in days. The bottleneck moved upstream, to whoever can decide what's actually worth building. That person has to be in the room.
- ▹Enterprise buyers increasingly want to own the IP rather than rent a SaaS seat. I wrote about that shift in SaaS Is Dead, IP Is Rising. Owning the IP only pays off if the code reflects your business precisely - which requires engineers who live inside your context, not across a ticketing system.
What An FDE Actually Does Differently
The difference between a Forward Deployed Engineer and a traditional consultant shows up in the small moments, not the org chart. A few examples from our current engagements:
- ▹They shorten the loop from 'observation' to 'shipped fix' from weeks to hours. When a sales lead complains about a broken export in a Tuesday standup, the FDE has already patched it before Wednesday's coffee. No ticket, no triage meeting, no requirements document.
- ▹They catch the requirements nobody wrote down. Every enterprise has invisible rules - the approval that always goes through Priya first, the region that runs on a different fiscal calendar, the customer segment that must never see certain fields. Those rules never make it into a spec. They surface in hallway conversations.
- ▹They protect the codebase from entropy. With AI generating code faster than humans can review it, someone senior has to sit close enough to the team to say 'no, we're not merging that' with authority and context. That's a job you cannot do from 8,000 kilometres away with a two-day Jira lag.
- ▹They design the seams where AI plugs in. Most of our current FDE work involves connecting internal systems to LLMs and agents through purpose-built middleware. I've written about why that seam matters so much in MCP Servers: The Missing Layer Between Your Software and AI. Getting those seams right requires understanding *this specific* business's data, permissions and workflows - the kind of understanding you can only build on site.
Why This Model Works Financially
The instinct many CFOs have is that on-site senior engineers must be prohibitively expensive. In practice, the opposite is usually true when you look at the whole system.
A single FDE, backed by a delivery pod in India, replaces a much larger and more expensive apparatus: the business analyst translating requirements, the project manager reconciling time zones, the architect flying in for workshops, the rework caused by misunderstood specs, and the internal team members pulled off their day jobs to explain things repeatedly. Cut those layers out and the effective cost per shipped feature drops sharply - often while the calendar time also compresses.
This is also why we don't sell FDEs as staff augmentation. An FDE only makes sense as the *front end* of a real engineering organisation. Alone, they become a very expensive contractor. Backed by a pod that can pick up work overnight, run QA in parallel, and hold the line on architecture and security, they become the highest-leverage role on the project.
When An FDE Is The Wrong Answer
I want to be honest about where this model doesn't fit. If your project is a well-scoped, stable piece of work with a clear specification and no meaningful business ambiguity - a payment integration, a migration, a well-understood mobile app rebuild - you don't need an FDE. A turnkey engagement out of Bengaluru will be faster and cheaper. The FDE model is specifically for the projects where the requirements are still forming, where the business context is dense, and where the cost of a wrong turn is high. That's most AI-heavy work today, and it's much of the serious enterprise modernisation we see.
It's also worth saying: an FDE only works if the client actually lets them in. If the plan is to seat the engineer in a locked room and forward them tickets, the model collapses back into normal outsourcing with extra travel costs. The value comes from proximity, and proximity has to be genuine.
How We're Deploying FDEs At AMT
We now offer Forward Deployed Engineers as a first-class engagement model alongside our turnkey and equity-partnership options. In practice that looks like:
- ▹A dedicated delivery pod in Bengaluru or Kochi running in overlap with your working hours, picking up implementation, QA, DevOps and documentation.
- ▹A shared operating rhythm so the FDE spends their time on judgement calls, architecture and stakeholder conversations - not on the mechanical work the pod can absorb.
- ▹A clear IP position from day one, because these engagements almost always produce code the client will want to fully own, extend and eventually license or resell.
If the last twenty-three years of building enterprise software have taught me anything, it is that the projects that succeed are the ones where the best engineers were closest to the actual problem. AI hasn't changed that. It has amplified it. The teams that win the next decade will be the ones who put senior engineering judgement in the room, and back it with serious delivery capacity behind the scenes.
If that sounds like the shape of a project you're planning, I'd rather have a technical conversation about it than a sales one. That's how we've always worked, and it's how the best FDE engagements start.