Scalability → Buildability

Teams usually mean load when they talk about scalability: more users, more requests, more data without the system falling over. I keep coming back to another kind. A codebase scales internally when each feature leaves behind primitives that make the next one easier to build.

Analytics makes the difference visible. When tracking is added after a feature, it becomes a parallel implementation with its own requirements and failure modes. Engineers ship the feature and return to add events. Analysts specify those events and wait for another release. The same tax repeats every time.

Putting the tracking contract into the component changes the shape of the work. A button can carry its event name, required properties, and expected behavior alongside its UI. Engineers inherit analytics when they use it. Analysts can inspect the component library to understand which data will exist. Product managers can include those expectations in the feature rather than in a second tracking document.

Composability

When tracking is native, components carry behavior and observability alongside their UI. A Subscribe button can maintain one contract for the subscription action, the event, and the properties downstream analysis expects. The design system then enforces more than appearance; it preserves how the product explains itself to the data pipeline.

AI tooling

This structure also gives coding tools such as Cursor something coherent to extend. The model can see that a button includes behavior, tracking, and tests, then follow the same contract when it generates another component. The AI is not creating the composability. It is revealing whether the system had enough structure to make the next feature cheaper than the last one.