case study · theme · metafields · metaobjects
Metafield-driven merchandising on a stock theme
Background. For the same home-goods brand, most merchandising changes — sale pricing displays, mega-menu content, product badges — used to require a developer. The pattern that fixed it: the theme reads structured data (metafields and metaobjects) that non-developers edit in the Shopify admin, and renders whatever it finds. All three pieces below are live on the demo store; two have their own deep-dive case studies.
Promo pricing with an ownership guard. Products carry
promo_percentage / promo_amount metafields plus a date window, and
collection and product pages render struck-through compare pricing from them.
The subtle part is a field called promo_owner_product_id: when a merchant
duplicates a product, Shopify copies its metafields — but not its membership
in the discounted collection. Without a guard, the duplicate advertises a
discount the checkout won’t apply. The theme compares the owner field against
the product it’s rendering and suppresses the promo on any mismatch.
Editable navigation. The mega menu and the mobile drawer read
navigation_item metaobjects whose content_data JSON describes panels,
columns, imagery, and links. Merchandisers reorganize the navigation in the
admin; the theme just renders. Launch-day navigation changes stop being a
developer ticket.
Badges. Product cards show “New” / “Bestseller” style badges driven by
simple tag conventions plus a display_settings metaobject that caps how many
badges a card may show — a one-line rule that keeps enthusiastic tagging from
turning cards into sticker sheets.
Why this architecture. Every one of these features has the same shape: structured data in the admin, dumb rendering in the theme. It’s the shape that keeps clients independent — they change content, I only get called when behavior needs to change.