FDE as a service: you can hire the engineer, but not the feedback loop

You can now hire an FDE the way you rent a cloud resource. A.Team offers senior, customer-ready engineers who are placed with a vendor’s customers, work under that vendor’s name and handle the last mile.

The pitch is simple: close the deal, drop in a dedicated engineer, then pull them out when the job is done.

a16z looks at the FDE model from the risk side. The firm writes that the mistake is not doing services, but thinking of yourself as SaaS when you are really a services company with a platform attached.

Together, those two views raise a question every FDE should ask as early as possible.

The same work, sitting with the customer, wiring up data and fixing things until they run, can build an ever stronger product. It can also leave behind a string of projects nobody can maintain.

Which side you are on will decide much of what this career leaves you with.

Why is “services” a sensitive word?

The first reason is margin. According to N47, traditional services companies have gross margins of 30-40%, while software companies reach 70-80% or more.

Palantir is often cited as proof that the two can coexist. N47 says Palantir keeps gross margins above 80%, a software-level figure, despite heavy field deployment.

The a16z piece quotes an Everest report to explain why: unlike at a consultancy, at Palantir services are a means of getting customers to use the product, not the main source of revenue.

But the model is not cheap. Compound’s business model database quotes a former Palantir CFO: seven-figure contracts can support the model, and eight or nine figures certainly can.

A startup still signing small contracts should therefore think hard before copying the approach wholesale.

What do you get from copying half the model?

The easiest part of Palantir to imitate is sending engineers to sit with customers. The hard part is the platform behind them. a16z warns that a company copying only the field engineers ends up with thousands of bespoke deployments that cannot be maintained or upgraded.

N47 makes the same point differently: without a platform designed for composition and reuse, FDE deployments become expensive consulting projects. It also predicts that many companies trying the FDE model will drift into consultancies dressed up as software companies.

There is another drift mechanism, and it sits in the org chart. According to a16z, when FDEs are separated from the product team, the company loses its feedback loop and gradually becomes a pure services business. The engineers are still good and the customers still happy, but what is learned in the field never makes it back into the shared code.

The real test: is the next one cheaper?

Margin is the number a CFO cares about. Engineers have an easier test, and N47 states it neatly: each deployment should make later ones faster and cheaper.

Imagine you are an FDE at an AI startup selling an invoice-processing agent. The first customer runs a legacy ERP, and you spend a few weeks writing a connector, normalising data fields and building an eval set for their invoice templates. When a second customer in the same industry arrives, there are two scenarios.

In the first, the connector and eval set live in customer A’s repo, hard-coded to their column names. Customer B starts from scratch, and the company is essentially selling your hours.

In the second, you have turned the connector into a configurable module and moved the eval set into the platform. Customer B needs only a new mapping file, and your time goes into what is genuinely different about them.

Rocketlane offers a useful line for sorting everything you write: if a solution helps only one customer, it is customisation. There is nothing wrong with customisation, since every customer needs a little. The problem starts when almost everything you do falls into that category.

Three models, three fates for your work

There are three very different ways of operating, even though all three may advertise roles under the same FDE title.

Dimension	FDE driving product adoption	FDE hired out per deal	FDE drifting into consulting
What the service is for	Getting customers to use the product, not the main revenue source	Adding deployment capacity when a deal closes, without permanent headcount	Becomes the real revenue source, though the company still calls itself SaaS
Who keeps the knowledge after the project	The platform and the product team	The vendor, if it has a process to capture it; the engineer leaves when the project ends	Locked inside each bespoke deployment
Product feedback loop	The reason the model exists	Depends on how the vendor uses the hired engineers	Cut when FDEs are separated from the product team
Main risk	Needs contracts large enough to carry the cost	Knowledge leaves with the people	Thousands of deployments that cannot be upgraded

The middle column deserves the closest reading. A.Team’s model solves a real problem: vendors do not want to carry a permanent deployment team when their deal pipeline rises and falls unpredictably.

But when the engineer walks out at the end of the project, the question of who carries the lessons back to the product falls entirely on the vendor. Hiring someone to do the last mile does not mean hiring the feedback loop.

Rocketlane also notes that there is no single way to organise FDE work. The rental model can work well if the vendor treats hired engineers as an input to the roadmap. If not, it easily becomes the shortest route to the third column.

What does this change about how engineers work?

If you are an FDE, treat the share of reusable code as your own metric.

At the end of each deployment, ask what should go back to the platform, what is legitimate customisation, and what you hastily wrote for one customer when it should have been built for reuse.

The third question is the hardest to answer, but it is also the one that will help you improve fastest.

If you are a hired-out FDE, or at a small company without a mature platform, this discipline matters even more. You leave projects earlier than others, so handover documents, cleanly separated modules and notes to the product team are the only proof that you left something behind besides a running system.

In interviews, do not just ask how long you will sit with customers. Ask who FDEs report to, how field lessons reach the roadmap, and whether there is an example of a feature that came out of a deployment.

A company that answers these vaguely is probably in the third column of the table above.

On your CV, show that your work compounds from customer to customer. Do not just write “deployed for customer X”.

Write that you turned the connector built for the first customer into a module later deployments reused, or that a request you brought back became a feature.

Lines like these demonstrate exactly the “next one cheaper” test that N47 sets out.

Once FDEs can be hired deal by deal as a resource, being on site with the customer is no longer anyone’s unique advantage. What still sets you apart is evidence that after each of your visits, the company’s next deployment got lighter.