Baudie

Baudie sells scented personal care products. The storefront is a custom Shopify theme built from nothing, no Dawn and no purchased base, designed at Lumios Digital and developed entirely by me. Every page on the site is one I built.

It runs to roughly 27,000 lines of Liquid across 45 sections, 23 templates and 14 snippets, and I still develop and maintain it.

A theme can be built two ways. You can hardcode the pages the brand needs today, which is faster to write and looks identical on launch day. Or you can build a vocabulary of parts and let the brand assemble pages out of them.

The first option means every future change comes back to the developer. A new campaign, a reordered homepage, a seasonal hero: all of it is a ticket, a deploy and a wait. The theme is finished the day it ships and slowly becomes a constraint.

I built the second. Not because the founder wanted to do her own production work, but because a store that cannot be edited without a developer is a store that stops being edited.

Every section is written to be reused rather than to serve one page. That shows up as 543 settings across the section schemas, plus 21 repeatable block types. Copy, imagery, colors, layout direction, spacing, link targets and toggles are exposed in the theme editor rather than baked into the markup.

Product content is driven by 30 metafields rather than hardcoded per product. Scent names and notes, bottle sizes, ingredient lists, how-to-use copy and video, card images, portrait crops, hover states, gradient colors, card background and text colors, and the bundle upsell target all live on the product. Adding a product means filling in fields, not writing a template.

That combination is why the same section set produces genuinely different page types. The two clinical product lines do not use the standard product page at all; they use a landing page composition, built from the same parts.

The hardest single piece is the bundle. A customer picks several scents from a collection, and the page has to keep up: images swap as selections change, the price recalculates, and the whole thing has to arrive in the cart as a coherent order.

Most of the work is in what it refuses to offer. The selector reads from a collection rather than a fixed list, so new scents appear automatically, and it filters out anything unavailable or tagged as coming soon before a customer can pick it. An out-of-stock scent that is selectable is a bundle that fails at checkout, and the customer blames the store rather than the inventory.

It is built as a listbox with the correct roles and keyboard behavior rather than a styled div, which is the difference between something that looks like a picker and something that works like one.

The side cart is the largest file in the theme. It is a full cart surface rather than a drawer that links to one: line item editing, quantity changes and add-to-cart all run against the Shopify AJAX API without a page load, with upsells rendered inline from product metafields.

Getting this right matters more than it sounds. The cart is the last interface between a customer and a purchase, and every reload is somewhere to lose them.

Checkout is the one surface a theme cannot touch. Theme code does not run there, so the moment a customer has already decided to buy is the moment none of the above applies.

The straightforward approach is to build everything into a checkout extension: read the cart, decide what to offer, apply the discounted price from the client. Less code, works in a demo, and wrong. Anything running in the browser can be changed by the person running the browser, and a discount decided there is a discount a customer can rewrite.

So it splits into two deployed apps. A Checkout UI Extension in Preact queries the Storefront API and decides what to show. A Shopify Function compiled to WebAssembly and running on Shopify's infrastructure holds the pricing rules and applies them. The extension can suggest. It can never decide what a customer pays.

Both sides read the same field. A product carrying custom.upsell_price is an upsell product, and the value is its deal price. The cart drawer shows it, the checkout extension shows it, and the function charges it.

That is what makes new offers a content change rather than a deploy. The one-pack lands at its price and the three-pack at its own, and a future upsell product is covered by filling in a field. The merchant also controls the checkout block itself, with an enable toggle, the heading and the offered variants exposed as settings in the checkout editor, plus an admin panel rendered on the discount's own page.

The risk in that arrangement is drift. If the display rule and the pricing rule ever disagree, a customer sees one number and is charged another, which is the worst failure this system could produce. The shared rule is written down as an invariant in both codebases, and the display logic clamps to the variant price, so a mistyped metafield can never show a discount the function will not honor.

The deal only applies when the cart also holds at least one product that is not an upsell. Buying the wipes on their own pays full price, which is the difference between an add-on and a permanently discounted product.

Discounts are applied per item rather than per line, so any quantity lands exactly at the deal price. And it is deliberately one function rather than several: Shopify applies one automatic discount at a time, so splitting this across multiple discounts would have meant they compete. One function covers every upsell product and every quantity at once.

Discount logic fails quietly. Nothing errors, nothing appears in a log, and the store sells at the wrong price until somebody notices it in the numbers weeks later.

The pricing and eligibility rules are covered by 25 unit tests, and the function itself by integration tests that build the WebAssembly module and run it against fixture carts: an empty cart, a cart of upsell products only, a cart that should qualify, and the cases where the discount class is absent. Every rule described above has a test that fails if someone changes it.

The relationship started at Lumios Digital and continued independently after the studio wound down. I still build and maintain the storefront.