Build Product Previews From the Real Workspace

A polished product preview can become misleading surprisingly quickly. The page looks like the product, but it is really a separate hand-built interpretation of it. As the working surface changes, the preview quietly falls behind.

We found a simpler rule: when a landing or entry surface needs to show a real product capability, compose the domain-owned parts that already present that capability. Do not recreate their copy, selection state, or visual logic in a second “marketing” version.

The problem with a parallel preview

It is tempting to make a lightweight hero, AI welcome panel, capability list, and tool chooser specifically for the landing page. Each part seems small. Together they form another implementation of the product.

That creates familiar failure modes:

• the preview uses different labels from the working surface;
• it presents actions that the actual product no longer supports;
• it gets its own state assumptions; and
• a product change requires someone to remember two places.

The issue is not reuse for its own sake. A product page can and should have its own framing, pace, and calls to action. The question is who owns the things being shown.

Let the product own its meaning

A domain Workspace already knows which Entity is active, which capabilities exist, which actions are available, and how those pieces should be named. Those are product facts. They belong with the domain, not with a page that happens to introduce it.

The entry surface can compose that existing hero, contextual assistance, active-Entity chooser, capability list, and tool area in a different order. It may add product-specific discovery around them. But it should not maintain a second catalogue or re-derive the active context.

This is the same ownership principle behind an Entity spine: keep the shared framework shell thin, and let the domain that owns the behaviour own its implementation.

A practical test

Ask one question whenever a preview component is proposed: if the Workspace changes its name, current target, available action, or capability description, should this preview change too?

If the answer is yes, the preview should probably compose the source-owned component or source-owned catalogue. If the answer is no, it can be an independent product-story component.

That distinction keeps reuse deliberate. The product page owns narrative and navigation. The Workspace domain owns operational truth.

What we changed

We replaced a parallel landing implementation with composition of the existing Workspace sheets and domain capability catalogue. The visible product entry now draws its active context and available tools from the same owners as the working surface.

The result is less code, but the more important result is a clearer boundary: one product truth can appear in more than one place without becoming two products.

For future work, treat this article as orientation, not implementation authority. Verify current source, guards, and living context before changing a Workspace or product entry surface.