Nyyon · Blog

Everyone needs a forward deployed engineer. Almost no one should hire one.

The forward deployed engineer is the hottest job in tech, and a quiet verdict on how we build. SaaS was a workaround for expensive production. Now that building is cheap, the winning unit is not a platform for the average, it is the specific solution someone actually needs.

The hottest job in tech right now is one most people had not heard of two years ago. Forward deployed engineer. Postings are up more than 800 percent. OpenAI brought on roughly 150 of them through an acquisition. Salesforce committed to a thousand. Google Cloud, Anthropic, Databricks, and now EY are all standing up practices around the title. Mid level comp starts near 300k, senior roles clear 500k, and companies still cannot close the candidates.

A forward deployed engineer is simple to describe. An engineer who works inside your business, writes production code in your systems, and stays until the thing actually runs. Not a deck. Not a proof of concept. A working system, owned end to end.

It is worth asking why this role exploded now, because the answer is bigger than a job title.

Three figures: forward deployed engineer postings up over 800 percent, 88 percent of AI proofs of concept never deploy, and Gartner expects over 40 percent of agentic projects cancelled by 2027.

The boom is a confession

For three years the story was the model. Bigger model, better model, the model will change everything. The forward deployed engineer is the industry quietly admitting the model was never the product. The deployment was. You can hand a company the most capable model on earth and almost nothing happens, because the value was never in the model. It was in the messy last mile between a raw capability and a workflow your team actually relies on. That mile is human, and no amount of model capability closes it.

So the labs did the unglamorous thing. They started sending engineers to sit inside the customer and make it work.

SaaS was a workaround for expensive building

The way we have built software for twenty years is a response to one fact: building was expensive.

When building is expensive, you cannot afford to solve one person's problem. The math does not work. So you find a big market, a lot of people who roughly share a need, and you build one thing that serves the average of them. You pick that market carefully, because if it is too small there are not enough customers to pay back the cost of building. You ship a feature set aimed at the median user. And you ignore the edge cases on purpose, because every edge case is more expensive building you cannot justify.

That is software as a service. Not a philosophy, an economic workaround. One artifact, sold to many, because building a second artifact was too costly to consider. Generality was never the goal. It was the tax you paid for expensive production.

Two ways to build. SaaS: pick a big market, build for the median, ignore the edges, sell to many, generality as a tax. Service: one real need at the center, ringed by saves money, unlocks a deal, streamlines ops, adopted day one, built for one.

Cheap building breaks the whole model

Now building is cheap. The same AI native tooling that made the model famous made production fast. And when the constraint that justified SaaS disappears, the playbook built on top of it stops making sense.

Most people did not get the memo. They picked up the new tools and kept building the old way. Still chasing a big market, still shipping a median feature set, still ignoring the edges, still building another platform. New tools, old methodology. They are answering a need that is not quite there, because nobody actually wants another platform. People want their specific problem solved.

Ascending bars: expensive build means one thing for many, cheap build lifts the constraint, and the specific solution is one need, owned. Cheap production inverts the logic that made SaaS rational.

Your proof of concept did not die in deployment

You have seen the stat. IDC says 88 percent of AI proofs of concept never reach wide deployment. Gartner expects more than 40 percent of agentic projects to be cancelled by 2027. The usual reading is that deployment is hard.

That is the wrong diagnosis. These projects did not fail at the last mile. They failed at the target. They were built like little SaaS products, generic, for nobody in particular, aimed at the average of a market that does not need them. A thing built for everyone gets adopted by no one. The deployment was never the problem. The thing was.

The unit that wins now is a service, not a SaaS

When building is cheap, the winning unit is not a platform for a thousand people. It is a specific solution for one person whose need is real and measurable. If you solve this for me, it saves me this much money. It makes a deal possible that is impossible today. It takes an operation held together by spreadsheets and Slack and makes it just run.

That is not a SaaS. It is a service that uses modern tooling to reach a business outcome. Zoomed all the way in. Built against your real business, not the average of a market.

Which is exactly what a forward deployed engineer is. The whole industry just rediscovered, at enormous comp, that the valuable work is specific, owned, and bounded, not generic and permanent.

And that is the catch. The work being specific and bounded is also why hiring a forward deployed engineer full time is usually the wrong move. A single problem does not need a permanent headcount. It needs someone senior to own it until it runs, and then move on. Hire for the outcome, not the seat. Everyone needs the work. Almost no one needs the employee.


← All articles