Multi-surface product features that matter

A mature product is not only a marketing site. It is often a public marketplace or catalog, an authenticated operations portal, a desktop companion for heavy daily use, and a mobile app for people on the move—each surface composing the same domain resources differently.

The features below are the ones that repeatedly earn their place. They are described generically so you can apply them without binding to any single codebase or employer project.

If you are prioritizing a roadmap, ship shared auth and core resources before you polish a fifth client shell. Surfaces without a solid API become expensive demos.

Many teams start with a separate SPA for internal tools and another for customers. Over time, a single Next.js app can host both: public browse and checkout routes alongside authenticated ops dashboards. Middleware redirects keep old bookmarks alive during migration.

Shared session cookies across those routes reduce “log in again” friction. Role checks still belong on the API so a marketplace buyer cannot call admin endpoints by guessing URLs.

Migration tip: keep a registry of legacy paths and where they redirect. Users and support bookmarks survive years longer than you expect.

Navigation should make the two worlds obvious—public catalog versus signed-in ops—without forcing a full white-label split unless the business truly needs it.

Desktop and mobile earn their keep when conversation and alerts are first-class. Message lists, thread detail, and notification badges should use the same API resources. Voice or call features, when present, should obtain short-lived credentials from the API after the same authz rules as messaging.

Presence and typing indicators are best as lightweight signals—avoid writing every keystroke to the database. Ephemeral channels or short-lived records keep the system fast.

Unread counts should be consistent across web and mobile. Nothing damages trust faster than a badge that disagrees between phone and laptop.

Moderation and retention policies belong in the product early: who can delete messages, how long media lives, and what managers can export for compliance.

Order summaries, owner-wise analysis, purchase grouping, and ticket performance charts turn raw activity into decisions. Pair each chart with filters and a table. Export when finance or managers need CSV.

Keep report definitions close to the domain language users already know—location, shift, vendor, owner—so training time stays low.

Start with three reports people open weekly, not twenty reports nobody trusts. Depth beats a cluttered analytics menu.

Permissions matter: a location manager should not see every region’s numbers unless the role allows it. Enforce that on the API, not only by hiding menu items.

Referral programs and catalog-style listings are common growth surfaces. Treat them as real modules with settings, visibility rules, and audit trails—not one-off landing pages. The API should enforce who can create, approve, and redeem.

Public pages can stay cache-friendly; authenticated flows must stay session-aware. That split is normal and healthy.

Track attribution carefully enough to pay partners correctly, but avoid collecting more personal data than the program needs.

Status workflows (draft, published, archived) keep catalogs from becoming a junk drawer of outdated offers.

Desktop (Electron) shines for power users who live in the app all day: larger layouts, local notifications, tighter keyboard flows. Mobile focuses on triage—approvals, messages, quick status—on a smaller screen.

Both shells should reuse API clients and auth patterns from web. Feature flags can hide desktop-only or mobile-only experiments without forking business logic.

Release cadence differs: web deploys instantly, stores and installers lag. Design API changes to be backward compatible across that lag.

Offline-tolerant lists on mobile (cached last fetch, clear “you’re offline” banners) matter more than pixel-perfect parity with desktop.

Deep links should resolve the same resource on every surface: a message URL opened on phone should not dump the user on a marketing homepage.

Multi-surface products fail socially before they fail technically when permissions are vague. Define roles early: buyer, operator, manager, admin—and map every sensitive action to a role on the API.

Audit logs for money, membership, and data export build trust with B2B buyers. Record who did what, from which client type if useful, without storing secrets in the log payload.

Impersonation or “view as” tools for support are powerful; gate them tightly and log every use. They should never exist as an unsigned query param on a public URL.

Session revocation must reach every surface. Logging out on web should not leave a desktop token immortal unless you explicitly designed long-lived device sessions with their own revoke list.

First-run experience differs by client: web can afford a short guided tour; mobile should get the user to one useful action in under a minute; desktop may ask for notification permission at a calm moment, not on first paint.

Shared empty states help: if the catalog has no items yet, every surface should explain how to add the first one—or who to ask—rather than showing a blank table.

Invite flows should work from email on any device. Magical links that only open correctly in one browser break partner onboarding.

If you are building from scratch, a sane sequence is: auth and roles → core resources → web ops → notifications → reports → marketplace/growth → desktop/mobile shells.

Skipping notifications until after three clients exist usually means rewriting token registration twice. Doing reports before filters exist usually means rewriting charts twice.

Resist building a second mobile-only API “temporarily.” Temporary forks become permanent maintenance tax.

Measure activation per surface separately. A polished desktop shell with empty messaging is not “done.”

The important features are the ones that compound: clear roles, messaging people trust, reports they can filter, and clients that feel native without rewriting business rules for every shell. Build those well before chasing novelty.

Multi-surface success is less about having every platform on day one and more about shipping auth, core resources, and notifications in an order that does not force rewrites when the next client arrives.