The Palantirization problem

Andreessen Horowitz published the case for forward deployed engineering in June 2025. Eighteen months later, a different a16z partner published the case against copying it carelessly. Both are worth reading, and the second one is more useful if you are about to spend money.

The Palantirization of Everything, by Marc Andrusko, 16 January 2026, argues that many startups aspire to Palantir's model without the conditions that made it work, and end up with an expensive services business masquerading as a platform.

What "Palantirization" means

Andrusko defines it as four interconnected practices adopted together:

Forward-deployed engineering. Engineers embedded inside customer organizations for months.

Integrated platforms. Opinionated, unified systems rather than a loose collection of tools.

High-touch go-to-market. Long sales cycles into mission-critical environments.

Outcome-based pricing. Multi-year contracts blending software, services and optimisation.

Companies tend to adopt the first and fourth, which are the expensive ones, without the second, which is the one that makes them pay off.

The four conditions

This is the core of the argument, and it is the checklist to run before adopting the model.

Problem criticality. Palantir's early work was defence and intelligence, where the stakes justified bespoke deployment. Andrusko's contrast is blunt: optimising a sales workflow by 8 percent does not.

Customer concentration. Palantir served dozens of enormous accounts. A company chasing a fragmented base cannot afford an engineer per customer, and the arithmetic does not improve with scale.

Talent density. Palantir accumulated rare generalists comfortable with code, bureaucracy and high stakes simultaneously. That profile is hard to hire, which is consistent with First Round Review reporting that ten or more years at a large tech company can be a red flag for the role.

Platform backbone. Reusable microservices sat underneath the custom work. This is the condition that prevents the services trap, and it is the one most often missing.

Score yourself honestly on all four. Missing one is manageable. Missing two means you are buying the cost structure without the mechanism.

The services trap

Without a product foundation, Andrusko writes, embedding engineers becomes unmaintainable: thousands of bespoke deployments that are impossible to maintain or upgrade. Revenue scales initially and there is no compounding advantage and no durable moat.

The trap is dangerous because the early signals look like success. Contracts close. Revenue grows. Customers are happy, because each one got software built exactly for them. What is missing shows up two years later, when a platform upgrade has to be applied across forty forks and nobody can do it.

Revenue per forward deployed engineer is the number that detects this early, and the productization loop is the mechanism that prevents it.

What is actually portable

Andrusko's recommendations, which are the constructive half:

Time-box deployments with explicit constraints. An engagement without a stated end is the failure mode, which is the same conclusion AWS reached when it named customer self-sufficiency as a design goal of its own programme.

Build on reusable primitives rather than custom workflows. The custom layer should be thin and sit on shared infrastructure.

Integrate what the engineers learn into product discovery. This is the same point Marty Cagan makes from the product side: separating embedded engineers from product kills the loop.

Account for margin honestly. Do not claim software multiples on a services cost structure. The a16z case for accepting lower margin early is that it can climb: ServiceNow's gross margin at IPO was 63.2 percent and Workday's 54.1 percent, reaching 79 and 75 percent by 2024. The climb is the thesis, and it only happens if the productization actually occurs.

The five pressure-test questions

Andrusko poses these for investors. They work at least as well for buyers, which is how we would use them.

Where does shared product end and custom code begin? A vendor who cannot draw that line does not know either, and you will be maintaining the custom part.

What does year-three margin look like on mature customers? If it never improves, the vendor has a labour business and your renewal price reflects that.

How many engineer-months from contract signature to production? This is the number that predicts your own timeline better than any case study.

What breaks if you sign 50 customers next year? A vendor whose model collapses under its own success is a vendor whose attention you will lose.

How do you systematically decline customisation requests? The best question on the list. A vendor with no answer will say yes to everything, and everything they say yes to is technical debt in a system you depend on.

Where we land

We sell this model, and we think Andrusko is right.

The version of forward deployed engineering worth buying is bounded: a named production date, a named handover date, a thin custom layer on shared infrastructure, and a mechanism that turns what was learned into something reusable. The version worth avoiding is an open-ended engagement where the vendor's revenue grows with your dependency.

His phrase for it is the right one. The minimum viable forward deployment needed to bridge an adoption gap should be a temporary bridge to a platform, not the permanent business model.

If you want the disqualifiers stated from the buyer's side, when forward deployed engineering is the wrong answer is the page. If you want the questions to take into a vendor meeting, that list is here.