Three Ships. Clean Skincare, Two Markets.
Context
Three Ships is a clean skincare brand selling direct to shoppers in Canada and the United States. The storefront is Shopify. The theme is Palo Alto 5.8.0 by Presidio Creative — a paid premium theme the brand bought. Not Dawn, and not ours. settings_schema.json records the version; the section architecture, the design tokens and the compiled runtime under all of this are the vendor's.
We say that first because it decides how you read everything after it. A large share of the builds recorded on this storefront are vendor sections or app templates we extended, configured or remediated rather than authored. Where that is true, the build page says so before it says anything else.
Storefront Facts
- Client: Three Ships — threeshipsbeauty.ca
- Industry: Clean skincare, direct-to-consumer
- Platform: Shopify. Theme base Palo Alto 5.8.0 by Presidio Creative, a paid premium theme
- Markets: Canada and the United States — two hostnames, two currencies, French as a path prefix on the Canadian domain
- Documented builds: 109 publishable builds across 57 capability areas
- Attribution mix: 76 Deploi-authored, 33 Deploi-modified-vendor
- Surfaces: landing, product, collection, global, home, blog, cart, search, account, checkout
- Status: live, verified 2026-09-06
Capability Coverage
Fifty-seven capability areas carry publishable builds here; these are ten of the deepest. Linked areas have a published hub.
| Capability area | Builds |
|---|---|
| Campaign landing pages without a page builder | 14 |
| Structured data for AI answers and rich results | 13 |
| Design system and component library | 10 |
| Editorial blog and content hub | 10 |
| Media and asset loading strategy | 10 |
| Brand story and editorial section system | 9 |
| Fixed bundles and kit merchandising | 9 |
| Multi-market storefront architecture | 9 |
| Premium theme extension and configuration | 9 |
| Metafield-driven PDP content blocks | 7 |
Ten smaller areas also have published hubs, with the builds documented here: art-directed hero and banner system 8 · vendor widget remediation 7 · collection merchandising and product rails 7 · custom site search and predictive search 5 · video and shoppable media 4 · mega menu merchandising 4 · faceted filtering and progressive grid loading 3 · guided selling quizzes and finders 3 · variant swatches and shade pickers 3 · AJAX cart drawer without an app 3.
Engineering Themes
One theme, two markets, and the difference runs all the way down. Three Ships doesn't run a subfolder market. It runs two hostnames — .ca in Canadian dollars, .com in US dollars — served by one theme, with French as a path prefix inside the Canadian domain. Liquid has no URL parser and no per-market schema helper, so the split is made explicitly: request.host decides which structured-data block is emitted, request.path is rebuilt by string manipulation to strip the /fr prefix before hreflang alternates are assembled, and the footer's country-and-language switcher posts through Shopify's own localization form so it works with JavaScript off — it changes the currency a shopper is charged in.
A deliberate structured-data program for AI answer surfaces. Thirteen publishable builds exist to make the store legible to search engines and AI assistants: hand-authored Product, Offer, FAQPage and shipping-and-returns markup on product pages, and per-collection BreadcrumbList + CollectionPage + ItemList + FAQPage graphs written as literals rather than looped over collection.products, because a merchandiser re-sort would change the markup under the crawler. Each is forked by domain so the canonical @id and the priceCurrency match the storefront the shopper is on. The furthest edge of it is WebMCP agent tools on the trial-kit product page: eight tools registered through navigator.modelContext, feature-detected so the page is inert in browsers that don't implement it, seven read-only and exactly one a write whose variant id is fixed server-side by Liquid, so an agent can't steer the call onto a different SKU.
Integration remediation — making bought widgets survive contact with a theme. A meaningful share of the engineering here exists only because third-party widgets had to be made to behave. The cart drawer, reviews, subscriptions, upsell, rewards and shoppable video are all apps, each rendering its markup after load and re-rendering on state change. So the theme carries a remediation layer: MutationObserver routines that correct vendor heading levels and inject styles into a shadow root page CSS can't reach, written to be re-entrant because a one-shot pass gets undone the first time a shopper changes a variant. A bridge turns a shoppable-video add-to-cart event into a real /cart/add.js call and refreshes the app-owned drawer. None of that is a criticism of the apps. It's the honest cost of a bought stack, and it's the line item nobody quotes you: the seams between vendors belong to whoever owns the theme.
Constraints We Worked Inside
The theme is the first constraint. Palo Alto is paid vendor code kept close to upstream, so the work is additive by default — new block types and new sections rather than rewrites, forks to a new section type rather than edits in place so existing templates keep their saved settings, and additions appended inside the vendor's own token snippet because there's no hook for extra @font-face rules. The runtime ships compiled with no source in the theme, which is why some patches are written against the DOM rather than an API.
The second is merchandising scale: roughly 133 product templates, 46 collection templates, and a catalog taxonomy living in legacy product tags that predate Shopify's filter metaobjects — which is why collection.liquid carries three mutually exclusive filter strategies. The live templates run one of them: Shopify's own facets, configured in the admin.
The third is the app stack. The cart drawer is app-owned. Three purchase-option apps can appear in one buy box. The page-builder landing layout is generated by its app, whose own banner warns it can be rewritten at any time. None can be asked to change behavior, so the accommodation is always theme-side.
Selected Builds
- WebMCP agent tools on the trial-kit product page — Eight
navigator.modelContexttools: product facts, ingredients, trust signals, market context, fit, add-to-cart. Deploi-authored. PDP. - Configurable PDP block system on the Palo Alto theme — The vendor product page extended to 25 merchandiser-orderable blocks, with a pre-pass that captures the subscription app block once and re-emits it inside the buy-box form. Built on Palo Alto; this is our modification.
- Collection page: three filter modes, in-grid promos and infinite scroll — Faceted, tag and group filtering, with promo tiles serialized into a delimited string because Liquid has no mutable array. Built on Palo Alto; this is our modification.
- Landing-page hero sections with a no-JS add-to-cart on page templates — a campaign hero pair whose CTA renders a real Liquid product form from a section setting, so the add is a plain browser POST on a template Shopify hands no product. Deploi-authored. Landing.
- Shoppable-video to cart bridge: Hue add-to-cart event wired into Rebuy's drawer — a listener that turns a video app's add event into a real cart write and brings an app-owned drawer into step. The player and the drawer are both vendors'. Deploi-authored. Landing and cart.
What We Would Not Claim
A large share of this storefront is a purchased theme we extended rather than authored. Palo Alto 5.8.0 is Presidio Creative's: its sections, its design tokens, its block schemas, its compiled runtime. The collection page, the cart line renderer and the product accordions described here are their sections with our code inside them, and we wouldn't describe any of them as a grid, a cart or a product page we wrote.
Several surfaces are third-party app templates we integrated rather than built. The page-builder landing layout is generated by its app. The rewards page mounts an app's widget. The cart drawer is owned by an app. Where a section is vendor code, we have said so on its page, in the fact strip, in words. Of the 109 builds here, 33 are recorded as modifications to vendor code. We are not claiming the storefront.
Five build records on this storefront are documented and not counted. Checked against the live storefront, the code each of them describes doesn't run there — so none of it is evidence of what this store does, and a total that included them would overstate the record. They are out of every figure on this page, out of every capability area above, and described nowhere in this section. They stay in our own record, as findings for the client.
All Builds
Twenty-seven build pages are published; the rest follow progressively. Nothing ungated is counted or listed here.
Product page — PDP block system · WebMCP agent tools · PDP content accordion · product JSON-LD layer · PDP FAQ accordion and FAQPage · widget DOM remediation
Collection page — Three filter modes and in-grid promos · size-pill quick add · collection card system · Bundles & Kits collection JSON-LD · subscription bundle grid
Cart — Inline size picker on upsell cards
Search — Tabbed search results page · filter-triggered promo cards
Landing and campaign — Landing-page hero kit · skin quiz entry sections · tabbed product slider · shoppable-video cart bridge · A–Z ingredient glossary · Shopify Forms host section
Blog — Editorial article template
Global — Mega-menu header · GA4 dataLayer instrumentation · tabbed mobile Shop menu · page-context dataLayer · font delivery and image preload · loyalty tier and subscriber segmentation
Ready to Build on a Theme You Already Own?
Most storefronts aren't greenfield. They're a bought theme, an app stack and years of merchandising decisions that all have to keep working. That's where we do our best work. Contact us today to talk about what your theme can be made to do.