Turning Custom Solutions Into Reusable Platform Capabilities

Most software companies build a product at headquarters and then rely on other people to get it working in each customer's environment. A product often does not yet fit what a particular customer needs. When that happens, someone has to close the gap. The question to keep in mind as you read this article is simple: when a product does not yet fit a customer's needs, who closes the gap, and how?

The phrase forward-deployed describes where the engineer works. In the early years of the model, being forward deployed was meant quite literally: engineers spent extended periods physically alongside the people who used the software, including in demanding settings. The source is clear, however, that the point of that proximity was not the setting itself. The point was the feedback loop that proximity makes possible.

Because the assignment is limited to one customer, an FDE is not spread across many accounts. The FDE is not there to win the contract, and the FDE is not there to hand over a report and leave. Those two concerns, winning and reporting, belong to other roles, which the comparison later in this article describes.

The model depends on a short feedback loop. An engineer inside the customer's environment sees a problem, fixes it, and tests the fix against real use. The whole cycle happens close to where the problem appears, so nothing has to travel far before it is acted on.

The source contrasts this with vendors that route every issue through a distant queue. Those vendors operate at a much slower cadence. The FDE model exists to remove that delay, and it does so by putting the engineer where the delay would otherwise occur.

The central image of the model is the gravel road. An FDE builds a gravel road, which is a fast, customer-specific, sometimes rough path from where the product is today to where this customer needs it to be. The road is not elegant, and it is not meant to serve everyone. It exists to get one customer moving.

The diagram shows the two states of the same piece of work. Before, the customer-specific road exists beside the shipped product, built by an FDE for one customer. After, the product team has examined several such roads, found the patterns that recur across them, and converted those patterns into a paved highway. A paved highway is a generalized capability in the core product, one that future FDEs can use without rebuilding it from scratch.

The metaphor captures the heart of the FDE model, and it works because neither half is sufficient alone. Without gravel roads there is nothing to learn from, because the product team has no real customer experience to generalize. Without highways, the same work would be repeated endlessly, with each FDE rebuilding what a previous FDE already built.

In this picture, the FDE sits between the customer's team and the work, building roads that carry one customer forward. The product team sits between those roads and the core product, looking across them for recurring patterns. The road is where customer-specific work lives, and the highway is where that work becomes shared.

The FDE role demands skills that ordinary software work does not always build, so the company eventually created a structured way to produce them. A rotation program called Project Frontline took ordinary software engineers and retrained them as FDEs. The source gives the count of more than 250 engineers who went through it. Its alumni now staff forward-deployed functions at other companies in the industry, including OpenAI and Anthropic.

The existence of a training program is itself evidence of the model's logic. The model depends on engineers who can work inside a customer's team, so the company built a deliberate path to create them rather than relying only on people who happened to have that disposition.

The two kinds of work are easy to confuse because both involve code that solves real problems. The FDE role is not a sales job and not a traditional consulting job. Comparing the three roles by what they aim to produce and when their work ends makes the difference clear.

The key difference is the output. A salesperson's work is measured by winning the contract, and a consultant's work is delivered as a report. The FDE's output is software that runs inside the customer's environment, and the FDE keeps working until that software functions.

The worked scenario follows a pipeline. Each stage hands its result to the next, and the stages run in the same order as the model's logic: customer-specific work comes first, then generalization, then the core product.

The pipeline ends in the core product, but it does not end the FDE's work. Future FDEs draw on the highway for the next customer, and when they build a road that reveals something new, the cycle repeats. The source describes the model as a continuing loop between the road and the highway, not a one-time handoff.