Who Owns the Roadmap? Six Ways to Build a Forward Deployed Engineering Business

Everyone seems to be gushing over the Forward Deployed Engineer (FDE) opportunity lately.

The hype is real. AI makes it fundamentally more economical to deploy engineers closer to customers, build bespoke solutions faster, and turn domain problems into software overnight. There is an undeniable market window here.

At the same time, not enough people are asking the right fundamental question:

Who owns the roadmap, and who captures the value created by closing these gaps?

From where I stand, there are six distinct positions an FDE business can occupy. From the outside, they all look like high-growth AI implementation plays. Under the hood, their underlying unit economics and strategic defensibility are vastly different.

Some represent genuinely new opportunities; others are just old wine in shiny new agentic bottles.

1. You don’t control the vendor’s roadmap. You’re selling time and materials.

You deploy engineers to solve customer problems using someone else’s product.

The customer has a requirement. The vendor has a product. You bridge the gap. You use AI to make bridging the gap easier.

You get paid for your time, expertise, and delivery capability. The vendor retains control of the product and the client decides which gaps to close.

This can be a perfectly good services business. Historically, you won by out-hiring or out-selling the competition.

AI is rapidly dismantling that truism. It makes engineering capacity vastly more productive and bespoke solutions far cheaper to deliver. Your competitors have access to the exact same powerful models and agentic stacks. The delivery advantage that once came from having more (or better) engineers is evaporating.

You can still win through better pipeline management and stronger customer relationships. But you’re increasingly competing around a commodity. A commodity that bridges the value gaps left by a roadmap you never controlled to begin with.

2. You control a layer around the vendor’s roadmap. You are a value added reseller (VAR).

You don’t control the underlying product’s roadmap, but you own the middleware, connectors, integrations, and vertical-specific functionality around it. Over time, you build IP that you can amortize across multiple engagements.

This is where things get interesting for FDEs. Customer proximity gives you a privileged view of the gaps in a vendor’s product. You can solve those gaps for individual customers, identify which ones recur, and turn the solutions into reusable IP.

In theory, this is how you escape the T&M trap.

The problem is that the cost of building this IP is collapsing. AI is turning your moat moot. A connector that once took a team six months can now be built in a fraction of that time. Vertical workflows that required years of specialized engineering are increasingly swallowed by open-ended agentic loops.

The cynical VAR has already adapted. He wraps his brand around the latest frontier lab’s model, calls it "Enterprise AI Transformation," and charges a fat implementation markup on top of an ever-growing token bill.

That might work for a few quarters. But if the underlying model is interchangeable, the implementation is trivial to replicate, and the platform provider controls the critical dependencies (i.e., the roadmap), you’ve just signed your own death sentence.

Why? As always, the devil is in the details. Go read your favorite model API’s Terms & Conditions. Pay particular attention to its disclaimers around stochastic outputs and non-deterministic failure modes, then compare them with your own E&O insurance policy that says you should know better. The truth is that what you promise your customers is never what your provider guarantees.

The solution is straightforward. Stop selling raw model deployments. Start building an opinionated roadmap around observability and traceability, around deterministic gates, AI routing, and agentic governance. The opportunity isn’t just to deploy the model. It’s to own the layer that makes it usable, reliable, auditable, predictable, and ultimately — boring.

That’s where the money sits.

3. You contribute to open source. You’re most likely building someone else’s moat.

Open source creates enormous opportunities for smart FDEs. You can build on the shoulders of giants. You share all the expensive pieces around services, distribution, hosting, and product development.

But contributing code is not the same as capturing value.

You may be improving a project, helping it win customers, and making it more commercially valuable as a whole without owning any of the resulting upside.

The risk is especially pronounced when you cannot maintain your own fork, influence project governance, or monetize the capabilities you develop.

That doesn’t make contributing to open source foolish. It means you need a deliberate strategy for capturing value from your contributions. AI acts as a double-edged sword. Contributing has never been easier but at the same time plenty of open source projects are collapsing under the curse of AI-slop.

Even worse is the structural value leak. When frontier model providers clio-kleptically ingest open-source codebases as raw training data, your bespoke solutions and domain-specific edge are synthesized into the next model weights overnight.

To survive, the FDE strategy around open source has to evolve. We’re heading toward an era of “peek licenses” and dual licensing, potentially paired with revenue-share agreements or commercial buyouts. These mechanisms have precedents in, for example, videogame development, but the matter hasn’t settled yet. The new question is how to apply these “licenses” when an AI lab or enterprise vendor indirectly incorporates a capability in its own products for free.

4. You can influence the roadmap. You’re a strategic partner.

Now we’re getting somewhere.

You have customer access, domain expertise, distribution, or implementation knowledge that the vendor values. Your feedback influences what gets built.

You’re more than a reseller or implementation partner. You help the vendor understand what the market needs, where its product falls short, and which gaps are worth closing.

But influence is not control.

The vendor can listen to your recommendations, incorporate your discoveries, and ship the resulting capabilities to every customer.

You may have accelerated its product development without creating a corresponding asset for your own business.

AI has made this risk even more pronounced. Frontier labs have an insatiable appetite for expanding their platforms, and the partner ecosystem can become a convenient source of product discovery, validation, and distribution. But once a capability becomes strategically important, the vendor has every incentive to absorb it into its own offering.

Look at the direction of products like Copilot for Legal and Microsoft’s Work IQ. Legal workflows that once required specialized implementation, proprietary playbooks, and bespoke integrations can increasingly be packaged as standardized skills that are shipped for free with a Copilot license. Context and integration layers that partners once had to build themselves have become native platform capabilities.

The customer problem hasn’t necessarily disappeared. But an entire layer of the market can lose its reason to exist.

That’s the strategic partner’s dilemma: you help the vendor discover what to build, prove that customers want it, and work out how to deploy it. Then the vendor productizes what it learned and captures the economics at scale.

You thought you had a seat at the roadmap table. Turns out, you were lunch.

5. You are Palantir.

Let’s not forget who came up with the concept to begin with. But Palantir is a beast of its own. Few businesses operate the way Palantir does.

To win at the Palantir strategy, you need infinite capital, ironclad NDAs, multi-decade government/enterprise relationships, and an unhealthy dose of hubris.

Palantir doesn’t just deploy engineers to fix a vendor’s product; they deploy FDEs to install their proprietary operating system deep into the client’s core infrastructure. They embed so deeply into the organization’s workflows that stripping them out becomes an operational and existential risk.

For 99% of AI startups trying to copy this, the Palantir path is a trap. The moment you deploy FDEs into enterprise clients, your engineering org splits into two separate worlds with competing realities.

The Front-House (FDEs) - Driven by customer proximity, empathy, and speed. They operate on commercial realism. They write quick scrappy code that solves a problem today. Their incentives are aligned with customer retention and immediate value delivery.

The Back-House (Core R&D): Driven by architectural elegance, scale, and technical beauty. They operate on long-term product roadmaps building generalized, reusable platform code. This creates massive product drift. Even if your FDEs have a seat at the internal roadmap table, there will always be a core engineer prioritizing technical beauty over commercial reality. Synchronizing the front-house and back-house is brutally expensive. You aren't just paying salaries; you are paying a constant tax on context-switching, internal politics, and architectural rework to merge bespoke client hacks back into the core codebase.
Palantir survived this because building two, three, or even more roadmaps isn’t a problem if your clients can print infinite money which governments tend to do.

6. There’s no forward or backward. You are an engineer deployed at the gate

You decide what gets bought, built, integrated, maintained, or retired. Which vendor capabilities are worth the price. Which gaps deserve custom software. Which connectors and middleware stay under the client’s control.

Historically, that seat belonged to the engineers in suits. McKinsey, Bain, and BCG told executives what to do. Accenture and Deloitte sent armies to do it. Strategy and execution were separate businesses, divided by months of analysis, layers of management, and millions in fees.

AI collapses that divide. Two or three elite engineers can now hold the authority of a boutique technical consigliere and the execution power of an engineering team. You don’t hand over a 100-slide deck and walk away. You find a costly business problem, decide whether to buy or build, and ship something that proves or kills the hypothesis. What once took a multimillion-dollar transformation program now happens in small, modular interventions inside the business.

Four moats make this work.

• Decision rights. You sit on the buyer’s side of the table. Every SaaS vendor is pushing copilots and agentic add-ons to win a bigger share of the budget. You tell the client which are worth the price, which are repackaged model calls, and which a lightweight custom tool can replace. Sometimes the answer is to buy. Sometimes it’s to build. And sometimes it’s neither: the client should change how they work. As Salesforce and ServiceNow push deeper into the SME market, this judgment gets more valuable. When an existing platform delivers 80% out of the box, the question is whether the last 20% justifies custom code or whether the client should adapt their process to the platform. Your incentive is the client’s total cost of technology, not a vendor’s ARR.
• The control layer. Model routing, deterministic guardrails, evaluation harnesses, permissions, observability, audit trails. This is what makes AI safe to run inside real business processes. The client owns it, so no model provider, no vendor, and not even you can hold them hostage. That’s what separates you from the VAR in Position 2, who builds a similar layer but owns it and sells it across clients.
• The context layer. A raw data lake is a swamp where agents drown, hallucinate, or leak. An ontology is the rescue rope. It turns messy, disconnected data into structured, permissioned, relationship-aware objects, so the AI reasons over business reality instead of statistical noise. You design it and maintain it. The client owns it.
• Accountability. This is the moat that gets paid. Model providers disclaim stochastic failures, and big consultancies disclaim operational implementation. You bridge that gap by taking technical responsibility for what runs in production: designing the deterministic fallbacks, building the continuous eval benchmarks, enforcing the permissions, and standing by the system when edge cases surface. You don’t try to act as an insurance company for non-deterministic AI risks. You build the governance harness that makes the client’s own risk committee willing to deploy and you build that governance harness in full transparency.

Yet even the engineer at the gate can fall asleep. Watch out for these three major execution traps: the talent bottleneck, the nightmare of stochastic accountability, and the irresistible temptation to drift back into building products.

The talent is rare. You need engineers who combine C-level communication skills, broad product knowledge, and deep technical expertise. These people are unicorns: expensive, highly sought-after, and rarely looking for traditional agency work. To scale such a business without diluting its authority, you cannot rely on a traditional junior-heavy pyramid or a fast-food franchise model. You build like an elite boutique law partnership or merchant bank: a high-margin, principal-led partnership that shares governance, shared IP libraries, and centralized back-office scaffolding. You don’t chase the $1B valuation but you don’t have to. You just give top-tier principal partners equity, operational autonomy, and institutional leverage, freeing them to do what matters: earn C-suite trust and solve high-stakes problems.

Accountability is a double-edged sword. It is the moat that gets paid, and it is also the one that can burn you. If you mistake technical governance for financial indemnification, enterprise legal teams will happily offload all stochastic tail-risk onto your balance sheet, a risk no boutique retainer can underwrite nor should underwrite. Your job is to point it out. The client’s job is to manage it.

The temptation to build never goes away. You advise on buy versus build, and you are an engineer. Some of you will always prefer to build, whatever the client needs or doesn’t need. The day your advice follows your taste and not the client’s interest, you lose the one thing you sell.

If you can overcome these, a new business model emerges. You operate on a recurring advisory and engineering retainer, ideally tied to outcomes: lower software spend, faster processes, fewer manual interventions, reliable AI in production. The best engagements compound. Every implementation adds institutional context, every vendor decision builds credibility, and every production system deepens your understanding of how the business really runs.
A roadmap was never just a list of things to build. It was a set of judgments about what mattered, what could wait, and what should never be built at all. Deployment schedules, vendor incentives, and the distance between decision-makers and implementers used to hide those judgments. Now the people who make them can also ship.

DISCLOSURE:
I run a business that operates as Position 6. That gives me a stake in this argument. I did my best to describe Positions 1 to 5 fairly, but please read the case for Position 6 with that in mind. I disagree with some of you, and I want to hear it.