What we mean by Forward Deployed Builders

Most consultancies staff a project by function. A designer for the screens, a product manager for the roadmap, a few engineers for the build, and a row of handoffs between them where the intent leaks out. We don’t work that way. We send Forward Deployed Builders: people who carry design taste, product judgement and engineering in the same head, sit inside your team, and own what ships.

Where the name comes from

Palantir invented the Forward Deployed Engineer in the early 2010s, and that is where the first half of our name comes from. The words are military: they mean working at the point of action, not from a rear base. They built the role out of necessity. Their customers often could not say what they needed until they saw it working. The only way to build the right thing was to put an engineer next to the person with the problem. You work it out in the real environment, not from a brief written at a distance.

We took that model and widened it. Our people are Forward Deployed Builders. Builder, not just engineer, because the job is design, product and code together, not one slice of it handed across a wall to the next slice. A product builder, in plainer terms.

It isn’t bodyshopping

The old consultancy trade is renting people by the day against someone else’s spec. You write the brief, they supply the hands, and the risk of the brief being wrong stays with you. A Forward Deployed Builder is the opposite arrangement.

They sit with the people who own the problem. They question the brief before building to it, because the brief is often the first thing that turns out to be wrong. And they carry the outcome, not the hours, on a fixed price for a defined piece of software. Human judgement is the whole point of the model. You are not buying a pair of hands to type what you already specified. You are buying someone senior enough to tell you when the thing you asked for is the wrong thing to build, and good enough to build the right one.

Why one role beats three

For most of software’s history you needed a team of specialists. No single person could hold design, product and engineering at a useful standard and also get through the sheer volume of typing a real product demands. Agentic coding changes the second half of that. The mechanical work, the boilerplate, the wiring, the first draft of the code, is fast and cheap now.

What stays scarce is taste and judgement. Knowing what is worth building. Working out what good looks like. Spotting whether the thing holds up when the inputs are wrong and the load is real. When the typing is no longer the bottleneck, splitting one product across three roles mostly buys you handoff loss. That is the slow leak of intent every time work crosses from one specialist to the next.

The industry is already naming this. The product engineer is now defined as someone who sets the product strategy and writes both the design and the code. Hybrid roles that span design and engineering are spreading, driven by the same AI tools. We think that is the shape of the work now, not a curiosity at the edges.

Where that leaves UI design

None of this means design goes away. It means the design work moves up a level.

When an agent can generate a competent screen from a good system, the value of hand-drawing the hundredth screen falls, and the value of the system itself rises. So the strongest design work is no longer drawing every component one at a time. It is setting the design system: the principles, the components, the type and spacing and behaviour, the taste that the system then enforces on everything built from it. A designer who owns the system shapes every screen without drawing each one. That is real influence over the product. The button drawn by hand for the fiftieth time is the part that thins out. Deciding what the button should be everywhere is the part that grows.

Human judgement is the job

The reason a Forward Deployed Builder works is that the hard parts of building software were never the typing. Getting a room of stakeholders who all want different things to agree on one of them. Reading whether the thing you have built is actually any good. Telling a client, with the evidence in hand, that their favourite feature should be cut. Making sure it stays safe, private and maintainable a year after the launch everyone remembers.

Agents help with none of that. They make the typing cheap, which is exactly why the judgement around it is worth more. So we put that judgement in one accountable person who sees the whole thing, rather than spreading it thin across a team and hoping it survives the handoffs.

What this means for you

You get a small number of senior people who own the product end to end, embedded with your team, on a fixed price. Not a rented team billing by the day against a brief nobody is sure of. If that is the shape of team you want on your problem, start a conversation →.