Project snapshot
Client / context: WebExercises / North Coast Medical
Role: Full-stack design engineer
Focus: New ecommerce storefront, affiliate attribution, provider-recommended patient products, cart and checkout flow
Stack: Next.js, React, TypeScript, React Query, Zustand, VSR API, hosted Stripe Checkout, Sentry, Plausible, Docker (following earlier Nixpacks deployment iterations)
The finished WebExercises storefront brings provider-recommended healthcare products into a focused, standalone shopping experience.
One-line version
I designed and built a new standalone storefront for WebExercises providers to recommend products to patients, preserving affiliate attribution from provider links through cart and checkout-session handoff.
The challenge
This was not an update to an existing product. It was a new effort: create a focused WebExercises product-store experience that could live outside the legacy ecommerce site while still connecting to North Coast product data, cart behavior, checkout, and affiliate tracking.
The business goal was the “Prescribe & Earn” model:
- providers recommend rehab products inside patient exercise workflows
- patients get trusted, provider-endorsed products in a simpler shopping experience
- providers can earn commissions when their recommendations convert
- North Coast gains a new channel for clinically relevant product purchases
The design challenge was turning that concept into a working product system: provider link in, patient shopping flow, cart management, affiliate attribution, and checkout handoff.
My role
I led the design-engineering work from greenfield implementation through production hardening. My work included:
- creating the new Next.js storefront architecture
- designing the patient-facing product browsing and cart experience
- wiring product/category data to backend APIs
- building bundle and affiliate-link handling
- implementing persisted, server-backed cart sessions and edit flows
- replacing the initial checkout integration with a typed V2 cart API and hosted Stripe Checkout
- adding observability through Sentry and Plausible
- hardening deployment through Nixpacks iterations and a final non-root Docker architecture
- creating audit scripts and documentation for product/category availability
Selected work
1. New storefront architecture
I built the storefront as a dedicated Next.js app rather than extending the legacy ecommerce interface. That gave the WebExercises experience its own product surface, routing, styling, state model, and deployment path.
The current architecture uses:
- Next.js app router
- React 19 and TypeScript
- React Query for server state and retry-aware API requests
- Zustand for persisted cart/session state
- typed VSR API clients and normalized response envelopes
- hosted Stripe Checkout for payment
The architecture evolved with the product. The initial storefront proved the patient flow with Snipcart-style cart behavior; the later implementation moved cart ownership into shared backend services while keeping a focused frontend boundary. This made the experience lighter than the legacy site without duplicating North Coast's product, pricing, and checkout systems.
2. Provider affiliate-link flow
The core interaction started with a provider-generated link containing an affiliate_id. The storefront needed to preserve that attribution as patients browsed, added products, and checked out.
I built handling for:
- reading affiliate IDs from query parameters
- storing attribution context on the client
- syncing bundle and cart requests around that context
- resetting stale bundle context when a new affiliate link was opened
- reconciling RX bundle carts so unrelated items were removed
- attaching affiliate metadata to cart lines and checkout-session requests
This made attribution explicit product behavior rather than background analytics.
3. Patient RX Cart and bundle bootstrap
Some patient flows start from a prebuilt RX-style bundle code. I built a bootstrap path where the storefront can load a bundle, add the expected items to the cart, avoid duplicates, and remove stale items that do not belong to the current bundle.
This mattered because the patient experience needed to feel direct: open provider link, land in relevant cart/product context, and move toward purchase without manual cleanup.
4. Product browsing and merchandising operations
I created the product browsing experience around categories, product cards, product detail pages, selected item variants, image handling, badges, related/additional items, and affiliate-eligible search.
Design details included:
- WebExercises-branded header and visual treatment
- product tags and primary badge styling
- free-shipping indicator and message
- category/product back-button behavior
- item and image-index support for showing the intended product image
- disabled/coming-soon states when products were not purchasable
- quantity controls and remove actions in cart editing
The catalog was not a one-time data import. I repeatedly reconciled stakeholder product lists with backend availability and affiliate eligibility, curated category membership, handled item-level exclusions, and built a CSV audit script that checked whether eligible products produced valid storefront pages. The result was a maintainable merchandising workflow rather than a generic catalog dump.
The category experience adapts the same product hierarchy, search, eligibility rules, and merchandising treatment across desktop and mobile.
5. Inventory-aware purchase decisions
Product availability could not be represented by a single enabled or disabled flag. I translated backend inventory data into patient-facing rules for purchasability, stock state, availability labels, maximum order quantities, and low-stock messaging.
I also simplified single-variant products so patients were not forced through unnecessary selection controls, while preserving full selectors for products with meaningful options. This kept backend inventory complexity out of the patient flow without hiding information needed to make a purchase.
The responsive product detail experience keeps imagery, availability, price, quantity, and purchase controls clear at each viewport size.
6. Replacing the first cart and checkout architecture
The storefront initially used Snipcart-style client cart behavior. As North Coast's payment platform evolved, I replaced that integration with server-backed VSR cart sessions and hosted Stripe Checkout.
This was more than a payment-button swap. I built:
- a typed V2 API boundary with normalized success and error envelopes
- retry-aware React Query behavior and persisted Zustand cart tokens
- normalization for evolving cart and checkout response shapes
- cart repricing and validation before checkout
- affiliate metadata on cart lines and checkout-session requests
- hosted checkout URL and Stripe session fallbacks
- return handling for success, pending, cancellation, and failure states
- fresh cart initialization after successful payment while preserving a reusable cart after cancellation or failure
I documented a manual verification checklist covering add-to-cart, validation, redirect, success, and failure paths. The migration aligned the storefront with North Coast's broader payment direction while keeping the patient experience continuous.
7. Operational hardening and observability
Because this was a new deployable app, I also handled production-readiness concerns:
- Sentry error monitoring with build-safe configuration and replay sampling disabled
- Plausible analytics replacing SolarWinds RUM
- Nixpacks deployment iterations followed by a multi-stage Docker build
- non-root runtime, PID 1, and healthcheck fixes
- Next.js, Node, and pnpm build fixes
- web audit tooling for reporting available products and categories
This kept the project from being only a prototype. It became an app that could be monitored, deployed, and debugged.
Design engineering approach
Build new, but integrate carefully
The product surface was new, but it still depended on existing product, affiliate, cart, and checkout systems. I designed the app as a clean frontend boundary while respecting backend realities.
Preserve attribution as product behavior
Affiliate tracking was not treated as hidden analytics. It shaped cart state, bundle behavior, checkout metadata, and provider value. That made attribution part of product design.
Keep patient flow simple
Patients should not need to understand bundles, affiliate IDs, item numbers, variant metadata, or backend product quirks. The UI absorbed that complexity so the purchase path could stay simple.
Delivered outcome
The WebExercises RX Cart project created a new ecommerce channel rather than modifying an existing one.
It delivered:
- a standalone provider-recommended product storefront
- affiliate-aware links from provider campaigns into patient shopping
- bundle-aware cart bootstrapping and cleanup
- patient-friendly product browsing and cart editing
- hosted Stripe Checkout support
- analytics, error monitoring, and deployment hardening
- product/category audit tooling for ongoing merchandising maintenance
What made this hard
The complexity was in connecting a new experience to existing business systems:
- affiliate attribution had to survive from URL to cart to checkout
- product data came from backend services with legacy constraints
- bundle context and direct shopping context had to coexist
- cart state had to avoid duplicate, stale, or cross-affiliate items
- provider marketing strategy had to map to patient-facing purchase behavior
- deployment and observability had to be solved alongside UX and code
Why it matters
This project shows a different side of full-stack design engineering than legacy modernization: starting from a business concept, creating a new product surface, and connecting it to the operational systems needed to make it real.
I did not just design screens. I built the app boundary, state model, API integration, attribution flow, checkout path, deployment strategy, and product-maintenance tooling.