PDP subscription terms — DES-52 handoff notes

Honest Anchor module for the EllieMD product detail page. Replaces the legacy "$ per month / full N-week supply" pricing grid that ships today on every PDP and category catalog tile.

v1.1 — 5/7/26. All product data verified against EllieMD Linear "Document Source of Truth" project. Mock catalog now reflects the same orderPrice, orderCycle, and copy that engineering will read from Sanity. Composite cycle data and the new DSIP, Selank, Semax SKUs from the 4/14/26 source-doc refresh are folded in. Tretinoin (a placeholder SKU not present in the source pricing data) is removed; EllieVate Skin+ (real SKU, 30-day cycle) replaces it as the short-cycle / non-week contrast.

Vocabulary alignment

This module renders strings directly from orderCycle, orderPrice, and prescriptionCycle. PDP, checkout, and account portal all use the same vocabulary so the patient sees one consistent way of describing cadence and renewal across the journey.

Renewal, Refill, and Reassessment are kept as distinct concepts. Definitions match DES-54 portal exactly:

• Renewal: the recurring charge to the card.
• Refill: the shipment that follows after provider review (account portal only — does not appear on PDP).
• Reassessment: the clinician re-check that gates each renewal.

PDP educational copy must preserve these distinctions rather than collapsing them into "your monthly order".

No "monthly" assumption anywhere. All cadence text flows through orderCycle.count + orderCycle.unit and pluralizes correctly across any value. The contract supports 'day' | 'week' | 'month' because the actual source pricing data uses all three (see "Cycle unit decision" below). Even SKUs with a 1-month cycle render as "every 1 month" — never "monthly". This is the central commitment of the module and the brief.

Deprecated terms — remove from the live PDP and catalog templates:

• monthSupply → derive everything from orderCycle.count + orderCycle.unit
• retailPrice (when used as a per-month figure) → rename to orderPrice and treat as the actual cycle charge
• weekSupply = monthSupply * 4 (line 167 of product_info.tsx) → delete the variable
• "$X per month" / "Per Month" labels → delete
• "Full N-week supply" labels → delete (the orderPrice IS the full-cycle supply by definition)

Dynamic vs static strings

Engineering needs to know which strings are interpolated from the API (orderCycle, orderPrice, prescriptionCycle) versus which are locked marketing copy that must not be edited per-product. The split below is the contract; everything dynamic is wrapped in a helper from lib/products.ts so there is exactly one place to change a phrase.

Hierarchy when both cadence and price appear (PDP variant, top-to-bottom):

1. Cycle price numeral — Lora 38px, the loudest element
2. Cadence phrase — sans 14px, baseline-aligned with the price
3. Per-day softener — sans 12px, secondary teal
4. Compound rhythm card (if applicable) — small white card, demoted from the price row
5. Renewal strip — icon + label + body
6. Reassessment strip — icon + label + body
7. Disclaimer rows (if applicable) — italic-muted info icon
8. Inclusions micro-line — italic, lowest visual weight

The price-and-cadence pair reads as one phrase visually. Renewal and Reassessment are explanatory and live below the trust-line so the patient encounters the headline price first, then the explanation, then the commitment ("cancel any time").

Source-of-truth audit (5/7/26)

Every product-specific value in src/lib/products.ts is now traced to one of the following Linear docs (project: EllieMD - Document Source of Truth):

Diff against the v1 prototype

Source vs patient-facing copy

A handful of strings come from internal/operational source documents (the pricing spreadsheet) rather than approved patient-facing marketing copy. They are preserved verbatim from source so the prototype is auditable, but flagged here for Stephanie review before patient exposure:

• orderCycle.description for MOTS-C, Tesa/KPV, DSIP — currently "8wk supply, 2wk break". Source-faithful but reads like internal shorthand. A patient-facing rewrite (e.g. "8 weeks of doses, then a 2-week break") needs Stephanie sign-off before it can replace the source string.
• Disclaimer copy on the nad-plus-restricted stress scenario is illustrative only — actual state-restriction and HSA/FSA language must come from EllieMD legal review, not authored by design.

Per the strict EllieMD rule (no invented content), nothing else in the data file is authored copy.

Cycle unit decision

The previous prototype's OrderCycle.unit was constrained to 'week' only, on the rationale that consistent units across the catalog simplify the contract. Pulling the actual source pricing data from Linear changed that picture: the catalog has three units in active use.

Two ways to reconcile:

A. Normalize everything to weeks at the data layer. EllieVate 30 days → 4 weeks; protein 1 month → 4 weeks. Pros: single unit simplifies helpers. Cons: lossy (30 days isn't exactly 4 weeks; "month" semantics get destroyed); also requires Lauren's source spreadsheet to be re-authored, which we don't own.

B. Expand the contract to 'day' | 'week' | 'month'. Helpers pluralize across all three. Pros: zero-loss faithfulness to source; the central "no monthly assumption" commitment becomes literal — a 1-month SKU renders as "every 1 month" instead of being silently turned into weeks. Cons: marginally more helper logic.

Chose B, aligned with the brief's anti-monthly stance. The helpers in displayInterval, pricePerDay, etc. handle all three units. The visual module is unchanged — every SKU still renders the same Honest Anchor block.

Open question for engineering: The Sanity schema needs to expose unit as an enum the same way. If Sanity already has a flat cycleWeeks integer, that needs to grow into { count, unit } to match the contract. Flagging for the PDP engineer (Samir / Amir).

Page hierarchy

Where the Subscription Terms module sits on the PDP relative to other modules. This is the focal block for conversion — between the trust-signal cluster (shopping benefits bar) and the action (Purchase CTA).

PDP — productInfo component

The brief asks for a positioning note. Concrete order top-to-bottom inside the live productInfo Sanity component (src/app/product/components/product_info.tsx):

1. Image gallery + product title (Lora) — primary identity
2. Product description (Sanity rich text) — secondary
3. Health benefits row (3 cards) — secondary
4. Quote / verified-user testimonial — trust signal
5. Shopping benefits bar (HSA/FSA, Free Shipping, 50 states, Medical Consultation) — trust signal
6. Subscription Terms — Honest Anchor module — conversion anchor
7. Purchase CTA — action
8. ↓ Then secondary modules render below in Sanity-defined order: banner · productShortBenefit · ferrisWheel · carouselMulti · video · experience · personalizedCards · productComparisons · howItWorks · productResultsInfoGraphic · testing · scientificSources · faq · readyToStart (per the PRODUCT_PAGE_COMPONENT_TYPES array in productPageV2.tsx)

The module sits above the fold on desktop. On mobile the Purchase CTA is sticky-bottom in production; the terms block scrolls into view immediately above the CTA so the patient cannot tap Purchase without having seen cycle price and renewal terms.

Category catalog tile — _products.tsx

The compact variant of the same module replaces the per-tile pricing block in src/app/(product_category)/_products.tsx (lines 188–208). Tile order top-to-bottom:

1. Product image
2. Title + tier
3. Category + formulation subtitle
4. Subscription Terms (compact variant) — cycle price + cadence + one-line renewal hint
5. Learn more link to PDP

Full Renewal / Reassessment strip lives only on the PDP. Catalog tiles are scan surfaces — the patient gets the cycle price and the "subscription, cancel any time" reassurance, then clicks through.

Cross-surface alignment

Mobile / desktop behavior

Both viewports are reviewable separately via the dev toolbar VIEWPORT toggle. Same SubscriptionTerms component renders in both — the divergence is at the page-shell level (product-page.tsx vs product-page-mobile.tsx, category-catalog.tsx vs category-catalog-mobile.tsx).

Module-level (SubscriptionTerms)

The module is a single component with responsive sizing. The two visible variants:

• Desktop: Lora amount 38px, padding 24px, full Renewal/Reassessment strip with icon + label inline.
• Mobile (375px frame): Lora amount 32px, padding 18–20px, renewal strip stays vertical, compound note stays full-width.

The <sub> for footnoted disclaimers stays inline at every viewport. The "As low as $X.XX/day" softener wraps below the price/cadence pair on mobile.

PDP shell (product-page-mobile.tsx)

Material differences from desktop:

1. Single column. No image-gallery / info two-column split. Image sits above the info stack.
2. Sticky-bottom Purchase CTA. The CTA is bottom-anchored inside the 375px frame. Patient cannot tap Purchase without seeing the Subscription Terms block, which scrolls into view directly above the sticky CTA. This is the central mobile composition rule of the brief — pre-purchase transparency requires the patient encounter cycle price + renewal terms before the action.
3. Shopping benefits bar drops to single column. Stacked checks instead of the desktop 2×2.
4. Inline gallery placeholder. Production uses a horizontal swipeable gallery; the prototype shows the same icon block desktop uses, full-bleed within the tile.

Order top-to-bottom inside the mobile scroll body:

1. Image
2. Title + tier
3. Description
4. Health benefits row (3 cards stacked)
5. Shopping benefits bar (single column)
6. SUBSCRIPTION TERMS — Honest Anchor module
7. (empty space below) — sticky CTA hovers

The desktop Position-relative-to-other-modules order (image→description→benefits→shopping bar→subscription terms→purchase) is preserved. The only divergence is the CTA mounting: inline on desktop, sticky-bottom on mobile.

Category catalog shell (category-catalog-mobile.tsx)

Single-column tile stack at 375px. Tile structure mirrors desktop (icon left, info right, compact SubscriptionTerms below). Smaller icon size (sm vs desktop md) so the info column gets more horizontal room. Compact SubscriptionTerms variant is identical across viewports — no per-viewport branching for the module itself.

Engineering implication

When integrating into the live repo, the live PDP and _products.tsx already have responsive styles for the surrounding shell. The SubscriptionTerms component drops into the existing mobile/desktop layout without further conditional rendering. The sticky-bottom CTA pattern in the production mobile PDP is unchanged — SubscriptionTerms simply replaces the legacy pricing block above it.

Category hero deviations

The brief asks for parity or intentional differences across category-specific heroes. Audit of the live (product_category) tree:

Conclusion: No category-specific hero currently displays subscription pricing. The default tile + PDP module pattern carries every category. When useHeroPersonalized ships for Microdose, the PDP module remains the canonical price surface — personalized hero may add testimonials or copy variations but does not duplicate cycle price.

Stress cases

The module degrades gracefully in each:

• Compound cycle (MOTS-C, Tesa/KPV, DSIP — all "8wk supply, 2wk break"): Rhythm renders in a small note card just below the price row, before the Renewal strip. Same pattern handles any future compound the catalog adds — the new Selank and Semax SKUs (4/14/26 source refresh) use the same structure and will render identically.
• State-restricted SKU with long disclaimer: Disclaimer appears as a third row in the renewal strip with the same icon-+-text atom, italic-muted to demote it. Wraps freely without breaking layout.
• HSA/FSA reimbursement footnote: Attaches to specific claims via superscript and lives in the inclusions micro-line. Doesn't fight the price-row hierarchy.
• Empty / loading state: Skeleton holds the same layout shape — no jump on hydration. Renders while orderCycle and orderPrice resolve from Sanity.
• Non-week cycle (EllieVate Skin+ at 30 days): Renders as "every 30 days" — explicit proof that the module never silently coerces to "monthly". Same Lora 38px treatment as week-cycle SKUs.
• 5-digit cycle price: Lora 38px holds 4-digit prices ($897, $1,297) without breaking the price-row line. The largest current orderPrice in the catalog is GLP-1/GIP/NAD+ Oral Drops Tier 3 at $1,497 — still 4 digits. If catalog adds a 5-digit price, drop to 32px and re-test.

Prototype to production component map

The prototype uses descriptive names that don't match the production filenames the ticket points engineering at. Mapping below.

Cadence handling rules

• All cadence text is driven from OrderCycle = { count, unit: 'day' \| 'week' \| 'month', description? }.
• Pluralize via ${cycle.unit}${count === 1 ? '' : 's'}. Centralized in displayInterval.
• The same row template renders 30-day, 4-week, 8-week, 10-week, 12-week, and 1-month cadences equivalently. No layout branches by count or unit.
• Short-cycle SKUs render as "every 30 days" or "every 1 month", never "monthly". This is the explicit commitment of the module and the brief.
• Compound cycles surface their on/off rhythm in orderCycle.description, not as a different unit. The contract count is still the full cycle length (e.g. MOTS-C count = 10 for a 10-week billing cycle, with description = '8wk supply, 2wk break').
• Per-day price computed via orderPrice / (cycle.count * daysInUnit[cycle.unit]), where daysInUnit = { day: 1, week: 7, month: 30 }. Rounded to two decimals. Centralized in pricePerDay.
• Renewal cadence and reassessment cadence are separate fields (orderCycle vs prescriptionCycle). Initially they hold the same values for every SKU, but the module renders them through different helpers so the two can diverge later (e.g. quarterly billing with annual reassessment) without a rewrite.

Pre-purchase transparency requirements

Per the brief: cancellation terms must be visible pre-purchase. The Renewal line carries the canonical commitment string:

Cancel any time from your account.

This is locked copy — it must appear inline with the Renewal explainer, not as a separate footnote, so it's actually seen. The compact catalog-tile variant carries an abbreviated form: Subscription · Cancel any time. Both are required pre-purchase by the brief and verified by stakeholder review.

Engineering touchpoints

Each surface in the prototype maps to a named engineering touchpoint, called out in JSX comments adjacent to the relevant section:

Shared utilities exposed by @/lib/products:

• displayInterval(cycle) → "every 8 weeks" / "every 30 days" / "every 1 month"
• priceCycleLine(price, cycle) → "$478 every 8 weeks"
• pricePerDay(price, cycle) → "$8.54/day"
• renewalLine(price, cycle) → "Your card is charged $478 every 8 weeks. Cancel any time from your account."
• reassessmentLine(prescriptionCycle) → "Your provider re-checks your prescription every 8 weeks before each renewal ships."

Pending review (before merge to live PDP)

1. Stephanie copy review of compound description strings ("8wk supply, 2wk break" is currently surfaced verbatim from source — needs patient-friendly rewrite or sign-off as-is).
2. Engineering confirmation (Samir / Amir) that the Sanity schema can expose OrderCycle.unit as the three-value enum, not a flat integer.
3. Legal review of disclaimer copy in the nad-plus-restricted stress scenario before any state-restriction or HSA/FSA strings ship as production copy.
4. Lauren confirmation that the four catalog scenario products (NAD+, MOTS-C, Tesa/KPV, DSIP) are the right four to lead the Longevity category landing — these were chosen as the prototype's Longevity-only catalog grid based on PSQ Compound Families groupings, but the live category landing may include more SKUs.