13:14 - 15:07
Q&A: choosing the granularity of shared primitives
Video segment: 13:14–15:07
The central question in this Q&A is not whether a platform should have shared primitives. It is how much work each primitive should already do.
The speaker’s answer is deliberately conditional: the right level depends on the industry, the use case, and how broad the platform’s user base is. A useful platform gives forward-deployed engineers a strong starting point. But a starting point that is too fixed can prevent customers with unusual needs from succeeding.
The terms: primitive, granularity, and atomicity
A shared primitive is a reusable building block on a platform. Earlier in the talk, shared primitives are what let an FDE assemble a customer solution without writing every part from scratch for every customer.
Two related words describe the size of that building block:
- Granularity means how large or small the pieces are.
- Atomicity here means roughly the same thing: how much a primitive does as one unit. A more atomic design breaks a capability into smaller pieces.
A coarse, high-level primitive may solve a large part of a common problem by itself. A fine-grained primitive gives the engineer smaller controls to combine or configure.
Neither extreme is automatically better.
| If the platform offers… | It helps when… | It can fail when… |
|---|---|---|
| A robust, mostly prebuilt application | many customers have a similar workflow and want fast delivery | a customer needs to change an important part of the workflow |
| Small, granular tools and configuration | customers have genuinely different or unusual requirements | every customer must assemble too much before receiving value |
In this context, robust means the base solution already handles a meaningful amount of the job. Configuration means changing behavior within the provided tools, rather than rebuilding the whole system.
A product boundary, not a universal percentage
The speaker gives an illustrative shape for one end of the spectrum: a platform might provide an application that is roughly 60% built, with the remaining 40% customized for the customer.
The numbers are an intuition, not a rule or measured target. The point is that the platform can carry the common work while leaving a deliberate customization layer for the customer-specific part.
For example, imagine a platform that already provides a common operational application. An FDE could adapt its workflow, fields, rules, and outputs to a particular customer rather than creating a new application from an empty repository. The platform supplies leverage; the customization supplies fit.
At the other end, some industry use cases require much more detailed configuration and tooling. The speaker’s point is not that every platform should expose all possible low-level controls. It is that a platform must leave enough control for the variation its users actually need.
Why this matters for FDE economics
Shared primitives reduce repeated work. If an FDE starts from a useful data model, service, or application base, they can spend more time on the customer’s distinctive problem and less time rebuilding common infrastructure.
That is the architectural constraint behind the earlier distinction between FDE and a development shop. Customer outcomes may be customized, but the company cannot sustainably recreate the technical foundation for every account.
There is also a counter-pressure. A primitive that is too large may encode one customer’s workflow so strongly that another customer cannot adapt it. In that case, apparent reuse becomes a constraint rather than leverage. Granularity is therefore a design choice about where the platform stops and customer-specific assembly begins.
The AWS analogy
The speaker compares this idea to AWS. AWS offers shared infrastructure services, including a database service in the example, so a user does not need to build database infrastructure from scratch.
The analogy illustrates the value of a reusable service boundary:
Without a shared service: build infrastructure → then build the application
With a shared service: use the service → build the application-specific behavior
An FDE can similarly begin with a platform data model or service and focus on the customer-specific solution. AWS is an analogy for shared infrastructure, not evidence that every business platform should copy AWS’s exact services or level of abstraction. The transcript’s exact AWS service name is unclear.
Choose for the breadth and variation of users
The speaker says that the right answer depends partly on the breadth of the user base. A broad user base often contains more different workflows. That increases the value of primitives that can be configured or combined in different ways.
Conversely, when many users share a stable problem, a more complete prebuilt application may be the better primitive. It lets the team deliver value quickly and avoids making each customer reconstruct the same solution.
A practical way to reason about the boundary is:
- Identify the work that recurs across customers.
- Put that recurring work behind a reusable primitive or prebuilt base.
- Identify the variation that customers truly need to control.
- Provide an appropriate customization layer for that variation.
- Revisit the boundary as the platform reaches new industries or use cases.
This is teaching context that makes the speaker’s tradeoff explicit; the video does not provide a formal decision framework or a fixed threshold for choosing the boundary.
Do not confuse “more atomic” with “more reusable”
It is tempting to assume that the smallest possible primitives are always most reusable. They may be flexible, but they can also push too much assembly work onto every FDE and customer project.
The opposite assumption is also wrong: one large abstraction will not fit every industry. Reuse comes from choosing a boundary that captures what is genuinely shared while preserving control over meaningful differences.
That balance supports the talk’s larger model. FDEs can deliver tailored outcomes at scale only when the platform is reusable enough to avoid reinvention and flexible enough to serve the customers the business chooses to support.
Source boundary
The source states that primitive granularity depends on industry and use case; contrasts a mostly built application plus customization with highly granular tooling; uses an illustrative 60/40 split; and uses AWS as an infrastructure analogy. The transcript appears to skip or compress an audience exchange near 14:48–15:05, so no missing question or answer has been reconstructed here.