OM
EN ES

Situation

Content and commerce experiences spanned Sanity, HubSpot CMS, Drupal, and Shopify. Each integration pushed its own shapes into the UI, which made cross-surface features expensive and brittle—especially once catalog, cart, checkout, and payments entered the picture.

Task

Define stable frontend contracts—data shapes, errors, and schema-vs-UI ownership—so CMS differences stayed at an adapter edge, with a separate commerce contract for catalog, cart, checkout, and payment flows.

Action

Normalized host payloads before presentational layers. Kept ownership explicit: who changes schemas versus who consumes UI. Applied the model across Shopify (smart cart, Stripe-adapted checkout UI), Sanity (reusable page components), Drupal (module boundaries), and HubSpot (CMS surface and UI fixes)—without leaking CMS APIs into feature components.

Result

Engineers could reason about one contract model while still supporting multiple CMS backends. Integrations became swappable at the adapter layer rather than rewriting feature UI.

System shape

Shared frontend contract: data shapes, errors, and ownership (who changes schema vs who consumes UI).

Commerce contract: catalog, cart, checkout, and payment edge—kept distinct from generic content composition.

Flow: host request → adapter normalizes to the right contract → UI renders the contract, not the raw CMS API.

CMS / commerce host → adapter → content or commerce contract → UI

Decisions

Stable frontend contract vs CMS shapes in the UI

Chose: one stable contract that feature UI could trust. Rejected: letting each CMS push its native shape straight into components. Why: cross-surface features stop being rewritten every time the backend changes.

Explicit ownership vs “whoever touches it, changes it”

Chose: clear schema-team vs UI-team boundaries, with consumers notified on schema change. Rejected: undocumented schema edits that surprise the UI. Why: a contract without ownership is paper; silent schema drift breaks the edge you just built.

Integration vignettes

These are patterns across hosts, not four separate full case studies.

Commerce edge — Shopify + payments

Smart cart and checkout-edge work, including a Stripe form adapted to the product UI. Commerce concerns (catalog/cart/checkout/payments) lived behind the commerce contract so payment and cart details did not spray into every presentational component.

CMS composition — Sanity

Page composition with reusable components on Sanity-driven pages. Content editors gained modular building blocks; the frontend consumed composed page structure through the content side of the contract rather than one-off page wiring per document type.

Module boundary — Drupal

New or evolved Drupal modules treated as bounded capabilities. Module boundaries mapped to adapter responsibilities so Drupal-specific APIs did not become the feature UI’s public interface.

Marketing surface — HubSpot

HubSpot CMS surface work included UI fixes and polish. Where the change was presentation-only, we did not invent contract ceremony; where the surface fed shared frontend experiences, the same “CMS stays at the edge” rule still applied.

What we refused

  • Schema changes without an owner or without notifying UI consumers
  • CMS shapes and APIs leaking into feature components

When this model does not fit

Skip full contract + adapter ceremony when:

  • There is a single CMS with no cross-surface reuse—the contract is overhead
  • The work is a short spike with no intent to reuse the edge
  • The CMS is the product (native admin UI) and there is no owned frontend to protect
  • The change is polish-only UI fixes without a contract change

Transferable lesson

Keep a stable frontend contract—and clear schema vs UI ownership—so Sanity, HubSpot, Drupal, and Shopify stay at the adapter edge; split out a commerce contract when catalog, cart, checkout, or payments (e.g. Stripe) enter the picture. Skip the ceremony for one-off CMS work, spikes, native admin UIs, or polish-only fixes.

Or shorter: the CMS is the edge; the contract (with an owner) protects the UI—and money flows deserve their own contract.

Limits of this write-up

Anonymized across clients and hosts. No proprietary schemas, internal endpoints, payment credentials, product screenshots, or client brand marks. Form-layering detail lives in the schema-driven forms case; this case stays on multi-host contracts and commerce edge. Client work under NDA — architecture and decisions shown, product details withheld by design.