Does needing FDEs mean the product isn't finished? Follow the custom code

“Done myopically, at one customer and for one customer, that is not a product, it is a project.” Thomas Otter, an investor, wrote that in December 2025, just as forward deployed engineering was being called the hottest job in startups.

Six months earlier, a16z had titled an analysis “trading margin for moat”, arguing that building transformative software often depends on labour-intensive services.

The two views meet at an uncomfortable question: if a company has to send engineers to sit with its customers, does that mean its product isn’t finished?

For a developer thinking of moving into an FDE role, this is not an abstract investor argument. Which side your next employer falls on will decide whether you spend the next three years learning to build products, or doing outsourcing under a more fashionable title.

The case for: AI automation has no plug-and-play version

The strongest argument for FDEs has nothing to do with unfinished products. Semafor, in a July 2025 article, explained why AI startups are copying Palantir, the company that popularised the role: for the kind of powerful automation AI promises, no solution works straight out of the box.

Picture an agent that reads invoices for businesses. The model may be good, but every customer has a different ERP, a different approval process, and data sitting in places only insiders know about. No software package solves those problems before someone shows up on site.

a16z takes the argument further. What margin buys is a moat, and that moat comes from controlling where and how customer data enters the system. Whoever sits beside the customer while the data is being connected writes the rules. Seen this way, FDEs are a deliberate investment, not a patch.

The case against: a project is not a product

Otter does not deny the value of working on site. His worry is elsewhere: startups that lean too heavily on FDEs risk drifting into consulting, and he states plainly that his fund does not invest in consulting firms. What he wants to see is a path to scale through product.

That worry finds support in a16z’s own piece. It concedes that the role is often an old professional services or implementation function with a new name, sometimes called FDE, sometimes implementation specialist or solutions specialist.

Valletta Software notes a more concrete detail: at platform companies, FDEs often report through the services organisation rather than the product organisation. Databricks is one example, advertising FDE positions inside professional services. Same title, but the org chart tells two different stories.

“Unfinished” has never meant failure

Otter himself supplies the argument that resolves the tension. Looking back at the early days of enterprise software, he recalls that products were still being developed when they were delivered to customers, not finished goods. He calls equating “in development” with failure a common misunderstanding.

So the question in the headline is aimed at the wrong target. A product that needs FDEs is almost certainly unfinished, and there is nothing shameful about that. The right question is: does each field deployment bring the product closer to finished?

The test is where the code ends up

Valletta offers a simple test. After each deployment, document what had to be customised and why, then push the reusable half into the core product. A team that skips this step, in its view, is really a professional services team dressed up as engineers.

A Substack essay from July 2026 makes a similar point: what separates FDEs from expensive consulting with a nicer title is an internal design decision, not the name.

Combined with Valletta’s two observations, that decision appears to turn on two questions: who do FDEs report to, and does the process require the step of feeding work back into the core?

The two questions are linked. An engineer who sits under the services organisation, as in the model Valletta describes at platform companies, is more likely to be measured by customer go-lives than by code that reaches the product. That is an inference, but it explains why the org chart deserves as much attention as the job title.

Return to the invoice-reading agent and suppose the company has three customers. At the first, the FDE writes a converter for that customer’s ERP format, notes which parts are specific to them, and extracts the generic file-reading logic into a connector in the product. By the third customer, if they use the same type of ERP, integration is just configuration.

A services team in disguise takes a different route: three customers, three code branches, three people who are the only ones who understand each branch. Revenue still comes in and customers are still happy, but the tenth customer costs nearly as much effort as the first. That is exactly the scenario Otter calls a project rather than a product.

Aspect	FDE as product strategy	Services rebranded as FDE
Reporting line	Tied to product, so reusable work has a route back to the core	Through services, as Valletta observes at platform companies
After each deployment	Customisation documented, reusable parts merged into the core	Custom code stays at the customer
Advantage that compounds	Control over how data enters the system	Relationships with individual customers, hard to scale
Tenth customer vs first	Markedly faster thanks to shared modules	Nearly the same effort
Investor view	Trading margin for a moat	A consulting firm, hard to fund

Read the job description like an org chart

Many Vietnamese developers have come through outsourcing and know the feeling of writing code for one client and leaving it there. If you are moving into an FDE role to escape that cycle, check before you sign. Don’t let the job title decide for you.

In the job description, look for two lines. The first says who the role reports to: product, engineering or services. The second says whether it mentions contributing back to the core product, building connectors or shared modules. A JD full of “deploy”, “support customers” and “ensure go-live” with nothing about the product is usually describing a services role.

In interviews, ask a specific question: what recent FDE work done at a customer has become a shared feature? A vague answer is still an answer.

On your CV, don’t just write “deployed for customer X”. Write it the way Valletta’s test frames it: what you built specifically for the customer, which parts you recognised as repeating, and how you turned them into something other teams reuse.

Written that way, your CV shows recruiters that you understand FDE work as a product strategy, not the project work Otter worries about.

The investors’ debate will eventually be settled by each company’s growth figures. An engineer can get a signal much sooner: open the git log and see where the code you wrote at a customer last month lives now.