Main idea

A lookup screen, an export, a dashboard, a query interface built by a product team sit alongside the product: they consume APIs, aggregate information, and produce an interface useful to whoever made it or to their team. What they break when they break is themselves.

A module, a journey or a functional variation built on the company's codebase sit in its extension. They reuse the existing building blocks, the business language in the code, the in-house components — and they live in the same repository, with the same dependencies and the same customers at the far end. What they break when they break is the product.

The distinction is not a difference of size or ambition: it is a difference of impact surface, and that is what should decide the level of requirement, not whether a product profile or a developer is at the keyboard.

Why it matters

It provides an operational criterion where the discussion usually stays on the level of the person. "Alongside" or "in the extension" can be established by looking at where the code lands and who depends on it; "competent enough" cannot be established at all.

It also traces two distinct and non-equivalent trajectories: relieving developers of small internal tools is a modest and reachable goal; letting product profiles contribute to the product itself is another subject, with other conditions.

Nuances and limits

The boundary is not watertight. A tool built alongside that writes to the production database has the impact surface of an object in the extension, whatever its location in the repository.

And the difference in risk says nothing about the difference in value: the most useful object is not always the one that touches the product.

Open questions

• How far can an organization let product profiles build in the extension of the product without losing technical control, coherence and security over the whole?