The Platform of Primitives
FDEs never write software from scratch. They assemble shared primitives into solutions arbitrarily valuable to each customer. Bespoke work stays scoped to its customer; anything generalizable flows back into the platform — and the field becomes the product team's scouts.
Here's the objection every smart operator raises immediately: you can't run design partnerships at enterprise scale, because you can't maintain the output. Build something custom for every single customer and you're herding cats — a pile of really bad code, fifty-five repos nobody wants to learn, and engineers who quit rather than maintain them. The objection is correct. It's also the exact line that separates an FDE function from what it isn't.
Never from scratch
What makes an FDE program different is that FDEs build on top of a platform. There is already a set of primitives — data models, workflow engines, integrations, an agent runtime — on top of which they assemble an application, a workflow, a solution that is arbitrarily valuable to that particular customer. Assembly, not authorship. That's the key ingredient, and it's what keeps a hundred customer solutions maintainable by one team.
click a piece to inspect it
How atomic should a primitive be?
It depends on who you serve. In some industries you can ship robust primitives — the app is 60% built and the customer's solution is the other 40% of customization. In others you need extremely granular tooling. The calibration question is breadth: AWS serves an enormously broad swath of customers, so it ships granular primitives like DynamoDB — the reason nobody has racked their own servers or invented their own database since the 90s. Your platform's job is the same at whatever altitude fits your market: absorb the undifferentiated work.
The sorting rule
Every line of code an FDE writes lands on one side of a rule:
- Bespoke and unique to one customer → it stays scoped to that customer, and only that customer.
- Generalizable → it should be generalized into the platform, in the long term, as a new primitive.
Early on you won't have many primitives — that's fine. FDE work is also a scouting function: it's how you discover, from real customer problems, which primitives and products to build next. The field feeds the platform; the platform compounds the field.
Palantir's ontology is the canonical primitive — no FDE ever defines a data model from scratch. The same pattern shows up anywhere the motion works: Anthropic's applied teams assembling deployments from the same agent tooling rather than bespoke scaffolds, or an agent startup whose fifth insurance customer takes days instead of months because the first four seeded the primitive library. And one operational rule travels with all of it: put two FDEs on a project, not one — a single engineer holding all the customer context is a single point of failure that goes on vacation.