Productionizing Custom Work
When does Palantir push a Delta's work into the Foundry platform? When does it stay bespoke? The rule of three, the handoff problem, and the contract you owe the team that inherits the code.
The bespoke-to-product gradient
Every successful FDE engagement ends in the same uncomfortable question: this thing works for this customer, what now? There are three end-states. Bespoke forever: it stays this customer's snowflake, you keep maintaining it, your company eats the cost. Product feature: the work gets generalized and merged into the main product, every customer benefits, this customer becomes one of many. Reference architecture: neither of those; you write down the pattern and let other FDE deployments reuse it, but each deployment is still its own codebase. Palantir's structural answer to this question is what produced Foundry. The Dev side of the org takes patterns that recur across Delta engagements and turns them into platform capabilities. The decision of what to lift and what to leave bespoke is made by what FDEs push back into the central repo, lesson by lesson, not by a single committee.
The rule of three
Don't generalize after the first customer. Don't even generalize after the second. The third customer wanting a similar capability is the signal that there's a pattern worth investing in. Before that, you're abstracting on top of a sample size of one or two, and the abstraction will be wrong. The cost of keeping two implementations slightly diverged for a year is much smaller than the cost of building a generic system that fits neither well. When the third customer arrives, take a hard look at all three implementations, find what's actually shared (it will be less than you expect), and lift only that. Leave the differences in the bespoke layer.
The handoff problem
An FDE engagement that succeeds has a built-in failure mode: the customer becomes dependent on you specifically. You wrote the code, you understand the data, you know which thing is faked, you know which manager hates which feature. When you leave, the system degrades, sometimes immediately, sometimes when something breaks six months later. Productionizing the work means transferring that knowledge somewhere durable, and the durable place is rarely a wiki. It is: tests that capture the customer-specific assumptions, runbooks for the three things you know will break, named owners on their side who feel responsible, and at least one engineer on your side who can answer questions when this customer pages in eighteen months. None of that happens by accident; you have to schedule it before the engagement is 'done.'
When to refuse to productionize
Sometimes the right answer is no. A customer-specific workflow that depends on a manual data export, a one-off prompt that captures three months of negotiation, a UI that exists only because their compliance team demanded it, these can be kept bespoke deliberately. Trying to push them into the product creates a configuration surface that costs more than the engagement was worth. The hard part is convincing your own company that 'we are not generalizing this' is a legitimate outcome, because there's an organizational pull toward turning every engagement into product features. A senior FDE pushes back against that pull when the math doesn't work. Palantir's own willingness to keep Delta work bespoke for the customer it was built for, rather than force-fitting it into Foundry, is part of why the platform stayed coherent.
The contract is the artifact
When work does get pushed into the main product, the most useful artifact is rarely the code; it's the contract you're now committed to. Every generalized feature comes with a maintenance obligation, a compatibility surface, and a customer who will complain when it changes. Write that contract down before merging. What is this feature promised to do? Who is the customer it was built for? What is allowed to change without notice, and what is now load-bearing? FDE-driven product features that skip this step accumulate quietly until the product team can't safely refactor anything. The contract is the gift you give to the engineers who'll inherit the work, and the document that protects you from being on the hook for every regression downstream.
Key takeaways
- •Three end-states for FDE work: bespoke-forever, product feature, reference architecture. Choosing wrong is expensive.
- •Palantir's structural answer to this question is the Dev vs Delta split: Devs absorb the patterns Deltas surface, and Foundry exists because that loop worked.
- •Rule of three: don't generalize until the third customer wants the same thing. Abstracting on n=1 or n=2 is almost always wrong.
- •Successful engagements create dependence on you specifically. Handoff (tests, runbooks, named owners, on-call coverage) must be designed, not improvised.
- •Refusing to productionize is a legitimate outcome. The organizational pull is toward generalizing everything; push back when the math doesn't work.
- •Productized features carry a contract. Write it down at merge time, or you'll regret it later.
Exercise
Think of one feature in a product you've worked on that was clearly built for one specific customer. Was it generalized too soon, too late, or correctly? What would have been different at each end-state? If you'd written the contract at merge time, what would it have said?
Self-check
- 1.What's the structural relationship between Palantir's Delta (FDE) work and the Foundry platform? Why is it not a coincidence?
- 2.Why is generalizing after the second customer often still too early?
- 3.What's the failure mode of a 'successful' FDE engagement where handoff isn't designed?
- 4.When is refusing to productionize the right call, and why is it organizationally hard to make that call?
Sources