Why Does the Nth Customer's Customization Volume Have to Decline?

Today's problems come from yesterday's solutions. — Peter Senge, The Fifth Discipline

"This customer is just like the previous nine — do we send another team of engineers?"

The tenth customer has just signed, and the project manager starts scheduling: connect the systems, configure permissions, adjust the workflow, build the evaluation, support after launch. Every item was already done on the previous nine projects, yet the schedule still reads as if this were the very first customer.

The real danger isn't that the delivery team isn't working hard enough — it's that the company never turned the previous nine deliveries into a capability the tenth one can use directly. Why does the Nth customer's customization volume have to decline? That's the question this chapter answers.

I. The Target Isn't Customization — It's Customization That Never Declines

The forward-deployed model was built on customization — this book has never been vague about that. A hundred percent customization for the first customer is inevitable: you're seeing what this industry's workflow even looks like for the first time, and there's nothing to do but customize. Criticism that treats "customization" as a dirty word is aiming at the wrong target.

What's actually fatal is something else: customization volume that doesn't decline with customer count. A hundred-percent-customized first customer is where the model starts; a tenth customer still 80% custom is where the model fails — because gross margin, delivery speed, and quality consistency will all degrade linearly with customer count, which the next two sections unpack.

So this chapter's question isn't "how do we do less customization" — it's "how do we make the Nth customer's customization volume significantly smaller than the first customer's." The metric already exists: the Customization Decline Rate, introduced in Chapter 19, with the reading rule spelled out in the open-source reference book — if it doesn't drop for three customers running, check the product feedback mechanism immediately.¹

Demand is moving the same direction too. One delivery lead at a major platform company said orders where the customer just buys person-days will keep shrinking — day-rate customization is, for both sides, an inefficient model of doing everything yourself, from building the henhouse to raising the hens to collecting the eggs. He drew the same distinction even for Databricks, known for its service revenue: what it does is "help the customer find the problem worth solving, not help them knock out the 100 feature requests on their to-do list."² As "buying features by the person-day" recedes, delivery organizations are forced to answer this chapter's question: if not by piling on headcount, what powers customization instead?

II. Two Cost Curves

Start by using the math to spell out what "dying slowly" actually looks like.

In a world without decline, the cost structure is a multiplication: total customization cost = number of customers × unit customization cost. Say each customer takes fifty person-days — ten customers is five hundred person-days — and team size has to scale linearly with customer count. This is exactly Vendor B's path from Chapter 19's three-year comparison table: gross margin locked down by labor cost, its most senior engineers burning out and quitting in year three. The gross-margin trap (Chapter 19) and this cost curve are two sides of the same ledger.

In a world with decline, the Nth customer's delivery cost gradually approaches the product's cost to replicate.

By the tenth customer, per-customer cost differs tenfold between the two worlds — and the decline world doesn't just save money: the delivery cycle shortens, and quality consistency rises at the same time. Decline isn't a cost-saving line item; it's the threshold this business has to cross to turn from a labor business into a product business.

III. When Customization Capability Only Lives in a Person

The problem isn't that a given FDE is too capable — it's that his judgment, his trade-offs, and his record of what went wrong stay locked in his own head. A ticketing integration built for the first customer gets rebuilt from memory when the fourth customer arrives; that's more practiced customization, not repeatable delivery.

Individual proficiency can keep improving, and customer count will keep growing too. If every delivery leaves nothing behind that the organization can use, customers will eventually outnumber what one person's capability can absorb.

The fix has the same shape as the external handoff in Chapter 17: deliver the system outward, accumulate knowledge inward. Every time customization wraps up, it should leave behind a list of reusable assets: which integration capability can be componentized, which processes can be turned into configuration, which evaluation structures can migrate, and which parts belong only to this one customer.

IV. Can the Contract Still Grow Without Customization Falling?

McGrew said on a podcast: the FDE strategy has to drive contract size up, doing increasingly valuable things for the same customer, so it's acceptable to keep a certain level of customization per customer, and the internal yardstick is contract size, not work per customer.³ "Customization roughly holding steady"? That's a direct clash with this chapter's title.

The key is the unit of measure: decline measures customization's share of delivery or contract value, not absolute hours. A single customer's customization volume can stay flat for a while; as long as product leverage keeps pushing contract size and delivered value up, customization's share still falls, and gross margin still has room to improve.

Lowering the numerator (less customization) and growing the denominator (bigger, higher-value contracts) are two readings of the same health metric. Most teams have to nail the first one first; the second only holds if the customization content is actually flowing back into product capability, continuously.

V. Three Kinds of Reusable Capability Behind the Decline

With the measure defined, the question is what actually drives the decline. Three engines, each backed by evidence from the field.

Set the ground rule first: customer data belongs to the customer and can't be carried to the next project. What actually accumulates across deployments is judgment about the scenario, methods of evaluation and verification, and the engineering process that turns "it ran once" into stable delivery.⁴

Capability one: componentizing integration capability. What's reusable isn't customer data, and isn't just interface code — it's a configurable set of integration capabilities: authentication methods, field mapping, sync rules, exception handling, and permission boundaries. Customer differences stay at the configuration layer; the stable parts move into platform components.

Capability two: turning processes into templates. Business processes common to an industry get abstracted into configurable templates. There's a line here that's easy to blur: configuration isn't customization — configuration changes parameters, customization changes code. The goal of templating is to downgrade "change the code" requests into "change a parameter" requests: approval tiers, field naming, and threshold ranges go into a configuration table; code only moves when the process topology itself changes.

Capability three: migrating evaluation structure. Evaluation patterns can accumulate across customers: task types, difficulty tiers, and judging rules are reusable; case data is not. What travels is "how to test," not the customer's "exam paper."

All three capabilities share one trait: every reuse makes the next delivery lighter. Platform components fill in exception handling, templates accumulate parameter experience, evaluation structures expand their library of failure samples. Reuse isn't carrying the old solution over unchanged — it's letting the reusable portion keep accumulating, so each next delivery gets a little lighter (see Figure 21-1).

Figure 21-1: Whatever new customization the Nth customer needs should be eaten away, layer by layer, by components, configuration, and platform capability.

VI. Where Configuration Ends and Customization Begins

Before the engines start turning, every request has to clear a gate at the door. Three questions, asked in order:

Question one: can configuration solve it? Anything a parameter, a template, or a rules table can handle is barred from touching code.

Question two: could this become a default capability for the next customer? Is this need unique to this one customer, or will other customers want the same capability too — if it's the latter, even if it has to be coded today, it should be written to the standard of a "future default capability": merged into the main branch, with proper abstraction, with parameters left open.

Question three: is this genuinely customization only? Unique to this customer, with no expectation of reuse — that's fine to customize, but the customization code must be tagged: one-off code has to be clearly marked and physically separated from product code. The tag isn't ceremony — it's what stops customization code from disguising itself as product capability. Half of the dead code discussed in the next paragraph gets in exactly this way.

Behind these three questions is a more fundamental directional call, from a delivery lead at a major platform company, put as a syllogism: customization, standardization, personalization. Software delivery used to work by "using customization to solve standardized problems" — encoding a business's already-smooth-running process into the system; get the encoding right and it solves 30% of it, get it wrong and there's "a fresh 70% increment every single day," turning the project into "a long, drawn-out black-swan engineering effort."² The agent era's opportunity runs the other way: "using standardization to solve personalized problems" — once workflows, data flows, and enterprise context are standardized, the same product can autonomously grow its own distinct traits at each different customer; whereas "once something is customized, it's hard to make it personalized" — customization locks down precisely the capacity to change.² Put into practice, that's exactly the direction the three-question gate pushes toward: keep downgrading "change the code" into "change a parameter," then let "change a parameter" settle into a preset capability the product ships with out of the box.

VII. Timing Productization: When to Abstract, When to Leave It Custom

Once the engines and the gate are both in place, what's left is a timing question: when to upgrade customization into product. The first customer usually has to go through the whole thing end to end, and the product team then abstracts out a general-purpose version from it that can serve the customers that follow.³

There are two common misjudgments here.

Stuffing one customer's solution straight into the product. It only solves one customer's problem, yet every future customer ends up paying its maintenance cost. A correct abstraction has to sit one level more general than the problem the customer brought in. Palantir, in its early days, moved away from building separate tables for concrete objects like "people" and "funds," toward describing the business using objects, properties, relationships, and actions — this modeling approach later crystallized into what's now called Ontology: instead of a separate table for every concrete object, a unified set of object types, property types, relationship types, and action types describes any category of entity (see Figure 21-2).³ Palantir's own materials position Ontology as "a digital twin of the organization," and stress specifically that it isn't a thin semantic layer on top — integrating data, logic, operations, and security together can't be done with a tagged field dictionary.⁵ Customer differences stay at the modeling and configuration layer; general-purpose capability stays at the product layer. How the Ontology keeps growing across customers and feeding the next delivery is taken up in Chapter 22.

Figure 21-2: Palantir's own Ontology teaching example (aviation); the English labels in the image are from the original and are left untranslated. Image source: Palantir's official documentation.⁵

Rushing to productize before a common signal shows up. Investing for future customers when there's still only one customer risks turning guesswork into platform features. The steadier discipline: don't rush to roll it out before there's a second customer; if a third instance of the same need still hasn't been acted on, that's when to check the feedback mechanism.

The signal can come from three places: the same process gets raised by two customers in different variants; pre-sales keeps demoing the same integration; a new customer proactively asks to reuse the previous solution. There's one more precondition: subsequent customers have to follow a similar business path. One practitioner's case: only after serving three to five customers in the same industry did the process gradually take shape as an agent product built for that industry.⁶

VIII. What Won't Decline: Book It as a Service Business

Some customization is naturally exempt from decline: a mega-customer's unique process (that's the vehicle for its competitive advantage, and it won't give ground for your reuse); differing compliance requirements across companies in a heavily regulated industry (different regulatory texts mean different obligations to rebuild for). The right way to handle this kind of need isn't to force it into the decline narrative — it's to admit it: this is a service business, so price it as a service business (the day-rate and blended structures from Chapter 20), book it separately (Cost to Serve from Chapter 19), and don't let it slip into the story of "we're building a product too" to inflate valuation expectations.

Honestly labeling the naturally non-declining portion as service actually protects the value of the declining portion — every point of drop on the decline curve is then real productization; lumping the two together and reporting a "product revenue share" is the most hidden version of the gross-margin trap.

Behind the falling curve is a hand carrying field experience back to the product. How that mechanism gets built, what gets carried back, who's responsible, how it's incentivized — the next chapter takes up flowing experience back into the product.

---

Footnotes

1. Fan Bing, Forward Deployed Engineer (FDE) (XDash open-source book) ↩

2. Silicon Valley 101, Episode 248: "China-Style FDE, with Alibaba Lingyang's Peng Xinyu" ↩ ↩² ↩³

3. Y Combinator, "The FDE Playbook for AI Startups" (Bob McGrew) ↩ ↩² ↩³

4. "Inside an Applied AI Company" (Pace long-form post) ↩

5. C26 ↩ ↩²

6. Turning Point (破局点), Episode 31: "FDE, Chinese Style" ↩