Modyu: B2C/B2B WooCommerce

ModYu is a new brand built around the HT4 Scalp Care System, a seven-product aftercare regimen for hair transplant patients. Williams & Crosby briefed a site that had to do two jobs in sequence: first introduce HT4 to the hair-restoration industry as a credible new product, then expand into a full e-commerce platform serving both retail patients and trade clinic partners, with a referral system tying the two together.

ModYu’s commercial model required three distinct user roles: retail Customers, Clinics, and Partners. Each saw different prices, different product visibility, and different purchasing flows against the same underlying catalogue. The hardest part was not the role separation itself but the pricing architecture beneath it. Every figure shown anywhere on the site, including net retail, VAT, and the 20%/25%/30% wholesale tiers, had to derive cleanly from each product’s underlying price and remain correct at every stage of the WooCommerce flow: product page, cart, and checkout.

A pricing mismatch anywhere in that flow would not just be a bug. On a site selling to patients at full retail alongside clinics at trade rates with VAT shown separately, a single wrong figure would destroy the trust the brand was being built on.

The HT4 product page itself needed to do real teaching work. The protocol is seven products applied in stages, which had to read clearly enough for a retail customer to make sense of it while showing clinics a more medically technical version of the same content. Standard product-page templates couldn’t carry that. The build needed bespoke widgets feeding from editor-managed content.

The site uses a fully bespoke WordPress theme with WooCommerce, with pricing and catalogue behaviour customised around three user roles: Customer, Clinic, and Partner. Each product has a standard WooCommerce price, and the theme derives the role-specific ex-VAT and partner wholesale pricing from that at runtime, using configurable tier settings rather than duplicated manual price fields. This means the brand can update the underlying product price and have the dependent on-site figures update automatically without maintaining separate customer, clinic, and partner prices by hand.

Partner pricing is implemented in custom theme code hooked into WooCommerce’s pricing and cart logic, so a Partner sees their wholesale price update as quantity thresholds are crossed, with the correct figures carrying through cart and checkout totals. Product visibility is role-aware too: each product can be restricted by role, so Clinics and Partners can see a different catalogue, not just different prices. Clinic users are also shown partner pricing as an upgrade prompt. Affiliate commission is handled separately via the Affiliate for WooCommerce plugin.

The HT4 product page uses three bespoke JavaScript widgets driven by ACF fields on the page edit screen, so the client manages all widget content through the standard WordPress editor. The seven-product widget walks visitors through each bottle one at a time, explaining its role in the protocol and listing its ingredients. A four-stage widget breaks the treatment process into its phases, and a tabbed information panel handles supporting detail. All three widgets are fully responsive, restructuring rather than just shrinking on smaller screens, and all three are role-aware: Clinic and Partner users see a more medically technical version of each product description, while retail visitors see the consumer-facing copy.

ModYu launched in two phases as planned. The industry-introduction site went live first, with the full retail and trade e-commerce platform following. Both are now operating across all three user roles, with the retail shop accepting customer orders and the trade area handling Clinic and Partner purchasing under the tiered pricing system.

The pricing engine, role-based visibility, and affiliate protection logic have held up in production. The client manages all product content, role assignments, and HT4 widget copy through the standard WordPress editor, with no developer involvement needed for routine updates.

One architectural decision worth flagging in retrospect: the pricing engine was built by hooking into WooCommerce’s own filters rather than overriding its pricing classes. Hooking is the slower, more conservative choice, but it leaves the site upgrade-safe when WooCommerce releases breaking changes, and any future developer can read the code path against WooCommerce’s public hook documentation. Overriding would have been faster to write and harder to maintain. If I were building this again I’d make the same call: the pricing logic is the trust spine of the brand’s trade relationships, and conservative beats fast there.