Shared Product Systems for Web and Mobile Without Forcing One UI Everywhere

Building a product for web and mobile creates a tempting question: how much can we share? The best answer is rarely “everything” or “nothing.” The goal is to share the decisions that should stay consistent while respecting the interactions that feel native to each platform.

Share the product contract

The most valuable shared code is usually below the visual layer. Types, API clients, authentication rules, validation, feature flags, analytics events, and domain-level state benefit from a single definition. When a conversation, entitlement, or user profile means the same thing everywhere, its contract should not diverge because two clients happened to implement it separately.

This is especially important for AI products. A message may be sent from a phone, continued in a browser, and processed by a streaming service. Shared types and well-defined events make that flow coherent.

Let the interaction be native

Web and mobile have different strengths. A web workspace can comfortably show dense information, keyboard shortcuts, multiple panels, and drag-and-drop. A phone needs direct navigation, sensible touch targets, and an interface that survives interruptions. Reusing a component mechanically can produce a UI that belongs to neither place.

I prefer to share design tokens and behavioral rules—spacing, color, loading semantics, error language, and permission states—then build platform-specific components where the interaction calls for them.

Keep navigation intentional

Navigation is a common place for accidental complexity. Deep links, auth gates, modal routes, and restoration after a notification all need predictable ownership. A simple rule helps: the server defines what the user may access, while each client defines the route and gesture that make access feel natural on that platform.

Test the seams

Cross-platform problems often appear where a shared state change meets a platform-specific screen: a streamed response resumes after a mobile reconnect, a subscription changes in one client, or a generated asset becomes available in another. These are the scenarios worth testing deliberately.

Sharing should reduce duplicate decisions, not erase thoughtful design. A shared product system works when the product feels consistent and each client still feels at home on the device where it runs.