Service-as-Software needs forward deployed engineers

It's an engineer who works for a single customer and builds everything that customer needs, and the name comes from Palantir. There, product engineers build the same feature for many customers. And the forward deployed engineers, whom Palantir calls Deltas, do just the opposite.

They work side by side with the client's team, learn how the work is really done and make the software do it. And Palantir judges them by the client's result, not by the code they ship.

The difference from a consultant is that a consultant recommends, while this engineer builds, ships and stays until it works.

Finished work can't be left on a shelf, because if it doesn't arrive, there is nothing to bill. A tool is different, since it can be sold and left there, and making it work is the buyer's job.

And that work lives in the client's systems: their CRM, their spreadsheets and the exceptions that aren't written down anywhere. So no AI model knows them until someone goes and takes a close look.

That's why companies that sell AI agents are hiring these engineers. In June 2025, the venture capital firm a16z went as far as calling it the hottest job in startups.

The model breaks when it's only half copied. In January 2026 Marc Andrusko, a partner at a16z, sounded the warning in “The Palantirization of everything”.

In his view, if you copy only the engineers on site, you end up with a pile of custom builds that no one can maintain or upgrade. And that, in his words, is an “Accenture for X” with a nicer front end.

Besides, most problems don't justify months of engineering on site. And people who understand both the business and the code are quite scarce.

So his advice is to treat these engineers as scaffolding: work on site with an end date, a limit on headcount and pieces that can be reused.

I work the way forward deployed engineers do, inside your company's systems, with its real data and alongside your team. It's how I already work at Sesame HR, where each team is an internal client, and I set myself three limits from day one.

The first is that the work at your company has an end date. The diagnosis picks one task, and the build phase ends when the system meets the agreed standard. After that I take care of maintaining it, with no more building.

The second is that what is not specific to your company is built to be reused, such as the checks and the results report. And only what is truly yours is made to measure.

And the third is that the cost of each task is measured from day one. That number is what tells you when engineering stops being the main cost, and whether the service is worth it.

Before you sign, I suggest asking any provider three questions.

Who will work with my team, and for how long?

What is built only for me, and what is reused?

When does the build phase end and maintenance start?

And if the answer is “as long as it takes”, you are probably buying hours rather than results.