Modernizing a Healthcare Ecommerce Platform from the Inside Out

Project snapshot

Client / context: North Coast Medical, ncmedical.com

Role: Full-stack design engineer

Focus: Practitioner-to-patient commerce, ecommerce UX, governed onboarding, checkout reliability, attribution, reporting, and operational tooling

Stack: PHP, WordPress, custom ecommerce layer, legacy API, MySQL/MariaDB, JavaScript, Stripe, Cloudflare Turnstile, Plausible, Retool, Holistics, SalesLoft, Vagrant/local VM tooling

One-line version

I helped modernize a complex healthcare ecommerce platform across the full practitioner-to-patient journey: onboarding and feature access, RX Cart workflows, product presentation, mixed-mode checkout, Stripe attribution, reporting, and production operations.

The challenge

ncmedical.com was not a clean greenfield app. It was a stitched-together production platform with real revenue, real clinical purchasing workflows, and years of accumulated business logic.

The system combined:

• a WordPress shell and custom theme
• a bespoke ncmecom storefront layer
• a legacy ncmedical-api backend
• Stripe checkout paths
• RX Cart practitioner-to-patient ordering flows
• customer/account-specific pricing and billing rules
• Retool and Holistics operational surfaces
• marketing, CRM, and reporting integrations

The design challenge was not only making screens look better. It was understanding how customer identity, practitioner permissions, feature terms, checkout state, product data, medical-account constraints, affiliate attribution, and operational reporting all interacted, then shipping improvements without breaking high-stakes production flows.

My role

I worked across product, UX, frontend, backend, data, and operations. My contributions included:

• shaping RX Cart as a practitioner workspace as well as a patient checkout flow
• redesigning registration and implementing feature-specific access and terms governance
• mapping legacy behavior from UI to API, session state, database rows, and third-party services
• implementing frontend, PHP, API, migration, and reporting changes in the production stack
• updating Stripe metadata, cart isolation, attribution, QR source tracking, and backend validation
• building operational reports and safer reward-reconciliation behavior
• creating runbooks and source-of-truth documentation for production support
• translating ambiguous business rules into shippable technical behavior

Selected work

1. Practitioner workspace and patient-cart product system

The work extended beyond checkout into the practitioner’s everyday RX Cart workspace. I improved bundle creation and editing, starter and account bundles, product-option selection, mobile navigation, QR distribution, patient-facing product presentation, and multi-image product data.

This made the system easier to use before checkout while establishing cleaner product identity and state for the order path that followed. It also meant resolving edge cases such as bundles with unresolved product options, account-specific recommendations, repeated patient sessions, and multiple orders opened back to back.

2. RX Cart checkout isolation and account handoff

RX Cart had to support guest self-pay, logged-in business account checkout, free-of-charge orders, workers-comp billing, and users who already had ordinary ecommerce items in their carts.

I implemented a safer checkout handoff model:

• guest and self-pay users remain in Stripe checkout
• logged-in business users can move into account checkout
• RX Cart orders use an isolated cart session
• existing ecommerce cart contents are stashed and restored
• rx_source_cart_token provides traceability across session, checkout, and order creation
• standard, FOC, and workers-comp branches follow distinct payment and account rules

This reduced the risk of mixing patient orders with ordinary shopping and made repeated patient-order sessions more reliable.

3. Provider onboarding, feature access, and terms governance

Healthcare ecommerce registration was not a single account form. Users could arrive as individuals, existing customer accounts, new organizations, practitioners requesting RX Cart, or organizations requesting additional software services.

I redesigned registration as a guided multi-step flow and implemented the supporting backend behavior, including:

• account and company branching
• NPI lookup and healthcare-service requests
• existing-user feature access requests
• administrator-aware permissions and inheritance
• versioned, feature-specific terms acceptance
• reusable access guards across protected RX Cart pages

This replaced scattered eligibility checks with a governed onboarding model that could support multiple services without turning registration into one enormous form.

4. Stripe attribution, QR distribution, and affiliate metadata

RX Cart attribution required item-level accuracy because one patient cart could contain products sourced from different bundles or affiliate contexts.

I updated Stripe checkout so every product carried the correct affiliate_id, rather than assuming one global source for the entire checkout. I also added source-aware bundle URLs and separate QR-versus-link engagement counters when those links were opened.

The tracking path preserves bundle and sharing context through patient cart and checkout flows. Unique bundle-user relationships and idempotent writes prevent missing tracking rows from turning legitimate opens into silent no-ops. Together, these changes created a more trustworthy attribution path for engagement, commission, reporting, and reconciliation.

5. Operational reporting and reward integrity

I expanded RX reporting and reward-management surfaces so product performance, order activity, affiliate earnings, and payout status were easier to investigate.

The work included:

• richer RX report views, filters, navigation, and pagination
• product-level reward and conversion reporting
• clearer tracing from users to bundles to orders and order items
• safer preview/update patterns for production reconciliation
• cancelled-order reconciliation that moves only unpaid rewards into a distinct cancelled state while preserving paid history

This turned scattered troubleshooting into repeatable operational behavior and kept reward rules consistent across RX commissions, VSR rewards, and backend reporting queries.

6. Secure registration and contact flows

I modernized the contact and registration paths rather than only documenting them. I replaced reCAPTCHA with Cloudflare Turnstile across both flows, separated page-specific JavaScript, added server-side verification, and instrumented registration-step completion with Plausible.

I also traced each request through browser validation, the ecommerce API bridge, backend validation, database writes, and notification email behavior. This improved both the user experience and the support team’s ability to diagnose failures.

7. Product, landing-page, and conversion UX improvements

I shipped targeted storefront improvements across product detail pages, landing-page templates, badge behavior, cart regressions, and mobile presentation.

Examples included:

• BD360 / Blue Diamond, FootWave, FEPsim, and GripWare/Norco landing experiences
• reusable branded landing-page structure and modal behavior
• FSA and RX Cart badge logic fixes
• cart-clearing, mini-cart refresh, and checkout-button regressions
• multi-image product presentation and mobile badge layouts

The work required moving between design intent, merchandising rules, CSS and JavaScript implementation, legacy PHP templates, and the product data feeding those interfaces.

8. A bridge to the modern VSR platform

Within the legacy storefront, I also built VSR landing, preview, navigation, reward, and category-consumer surfaces, then helped move category reads away from direct Ecwid dependencies and onto a more stable VSR API boundary.

That platform-side modernization is covered in the companion case study, Designing the API Platform Behind a Modern VSR Commerce Experience.

Design engineering approach

Start with system behavior, not screens

Many issues looked like UI problems but were actually state, identity, or workflow problems. Before changing UI, I traced how the user journey moved through sessions, account state, API calls, database rows, and third-party services.

Make legacy systems safer incrementally

Rather than proposing rewrites, I shipped narrow improvements that respected existing production constraints:

• isolate risky state instead of replacing entire flows
• preserve old paths while adding clearer rules
• add metadata and traceability where debugging was weak
• document behavior when code alone could not explain it

Treat internal tools as part of UX

The customer experience depended on admin workflows, Retool tools, reporting queries, and support visibility. I treated operations as part of the product surface, not an afterthought.

Impact

Because this was internal platform work, the strongest defensible outcomes are reliability, clarity, governance, and operational leverage:

• transformed RX Cart from a collection of legacy screens into a more coherent practitioner-to-patient workflow
• isolated patient-order state from ordinary ecommerce carts across guest, business, FOC, and workers-comp checkout modes
• improved item-level affiliate attribution across Stripe, order records, rewards, and reporting
• created governed onboarding with feature access, terms acceptance, and administrator-aware permissions
• made QR and direct-link bundle engagement separately observable
• preserved reward auditability when linked orders were cancelled
• replaced fragile form protection with server-verified Turnstile flows
• created reusable product, landing-page, badge, and image-presentation patterns
• strengthened the bridge between customer-facing UX and backend business rules

What made this hard

The platform carried real-world healthcare commerce complexity:

• account-specific pricing and billing rules
• mixed guest, patient, practitioner, and business-user flows
• legacy PHP and WordPress boundaries
• multiple API surfaces
• third-party dependencies like Stripe, Cloudflare Turnstile, Plausible, SalesLoft, Retool, Holistics, and the VSR API
• production flows where regressions could affect ordering and revenue

The work required switching constantly between interface design, backend implementation, data modeling, debugging, and stakeholder translation.

Why it matters

This project shows the kind of full-stack design engineering I do best: entering a messy, business-critical system; learning how it really works; designing better practitioner, patient, and operations workflows; and implementing the frontend, backend, data, governance, and support pieces needed to make those workflows reliable.

It was not a portfolio-perfect greenfield product. It was better: a real system with real constraints, where design quality depended on understanding the stack deeply enough to change it safely.