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 pretending to be 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.

Sales with a lot of personal contact. Long sales processes with customers whose systems must not fail.

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 profitable.

The pattern is easy to see once named. A founder reads about Palantir's growth, notices that embedding engineers and pricing on outcomes both correlate with large contracts, and copies those two practices directly. What gets skipped is the unglamorous platform work: the shared components, the ontology model, the internal tools that let one engineer do in a week what would otherwise take a month. Without that layer, embedding engineers and pricing on outcomes are simply an expensive way to sell custom software, dressed in the vocabulary of a platform business.

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 consequences 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 selling to many small customers cannot afford an engineer per customer, and the numbers do not improve as it grows.

Rare talent. Palantir accumulated rare generalists comfortable with code, bureaucracy and serious consequences 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 warning sign for the role.

A shared platform. Reusable microservices sat underneath the custom work. This is the condition that prevents the services problem, 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.

A useful discipline is to write the score down, not just think it through. Rate each condition true, partly true, or false, and attach one sentence of evidence to each rating rather than an impression. A rating of "partly true" for customer concentration that is backed by "we have twelve accounts above $500,000 in annual value out of two hundred total" tells you something specific about how much of your revenue could actually pay for embedded engineers. A rating with no evidence sentence attached is a hope stated as if it were an assessment.

Worth noticing that these four conditions describe a narrow set of businesses. Government and defense work meets the criticality condition by definition, and a handful of other regulated fields meet it because a wrong answer there is a reportable event rather than an inconvenience. Enterprise software selling to a small number of large accounts can meet the concentration condition. A consumer product selling to millions of small accounts almost never meets either one, which is exactly why forward deployed engineering shows up so rarely in consumer software and so often in defense, financial infrastructure and enterprise data platforms. If your business does not resemble any of those categories, treat that as a signal before treating the model as a strategy.

The services problem

Without a product foundation, Andrusko writes, embedding engineers becomes unmaintainable: thousands of bespoke deployments that are impossible to maintain or upgrade. Revenue grows at first, but no advantage builds up over time and nothing stops competitors copying the business.

The problem is dangerous because the early signs look like success. Contracts are signed. 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.

A concrete version of how this plays out. A company signs its first five enterprise customers, and each contract requires a different data model because each customer's internal systems are organised differently. The team, under deadline pressure, ships five separate codebases that each solve the specific customer's version of the problem. Every customer is satisfied. Revenue grows on schedule. Eighteen months later, the company needs to add a feature every customer wants, and doing that means touching five codebases separately, each with its own quirks, because nobody ever went back to extract the common structure underneath. What looked like five wins is actually five liabilities, and the company that seemed to be scaling was actually just adding headcount at the same rate as it added customers, which is not what a platform business looks like from the inside.

What can actually be copied

Andrusko's recommendations, which are the constructive half:

Set a fixed time limit on 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 small 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 stops that learning from reaching the product.

Account for margin honestly. Do not claim software company valuations for a business with services costs. The a16z case for accepting lower margin early is that it can rise: ServiceNow's gross margin at IPO was 63.2 percent and Workday's 54.1 percent, reaching 79 and 75 percent by 2024. That rise is the whole argument, and it only happens if the productization actually occurs.

The five 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 say where that boundary is 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 fails when it grows fast 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.

Our view

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

The version of forward deployed engineering worth buying has limits: a named production date, a named handover date, a small 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 conclusion is the right one: the smallest forward deployment needed to get customers using the product should be a temporary step toward a platform rather than the permanent business model.

Read against our own claim about writing code with AI, the argument sharpens rather than weakens. Generating code quickly does not by itself solve the services problem, because a fast custom fork is still a custom fork, and a company can generate its way into forty unmaintainable deployments just as easily as it can write its way into them by hand, only faster. What prevents the services problem is the discipline of deciding, on a schedule, what gets pulled out of the custom layer and into the shared one, and that discipline is a management decision rather than a technology one.

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.

Andrusko's problem-criticality condition is also the clearest guide to where the model does still fit: government and defense, where it was invented, and regulated work such as financial services and healthcare, where a confidently wrong answer is a reportable event rather than a bug.