Shop Canvas

I’m the founder of Shop Canvas. The problem I kept hitting on client work: teams design storefronts in Framer, run commerce in Shopify, and the glue between them either rents you a sync layer or pulls you out of the design model you chose Framer for.

Framer buyers want layout, motion, and CMS structure they control. Shopify holds variants, prices, inventory, and checkout. When those two worlds meet through a third-party bridge, someone else often owns the collection, the sync schedule, or the component model — and migration becomes the real product.

On Bouguessa — Shopify Plus, luxury fashion — I saw the same job from the theme side: editorial cadence and campaign layout matter as much as cart logic. Shop Canvas is that bet for Framer-led teams: design and CMS ownership stay in Framer; catalog and checkout stay in Shopify.

Buyers I have in mind: Shopify Plus and Framer-led brands (and agencies shipping many storefronts) with Bouguessa-shaped pain — publishing speed cannot wait on an engineering queue, but ops still live in Shopify.

Goal: connect once, sync into a Framer CMS collection the buyer owns, style code components on canvas, checkout on Shopify. Constraints: public Storefront API only (no Admin secrets in the plugin), producers not engineers as the primary installer, and trust that a bad sync must not silently overwrite live campaign rows.

Before locking architecture I ran Framer × Shopify competitive fieldwork (Notion: “Shop Canvas — Framer×Shopify competitive research,” ~Sep 2026). Method honesty: only a minority of claims were hands-on verified in that pass — on the order of five of forty — the rest stayed vendor-stated and labelled as such. I used the sheet to rank build priorities, not to quote market share.

Owned CMS, not a managed mirror. Preview-before-apply for every deliberate sync. Security boundary by design: Storefront token in the plugin; card data only on Shopify checkout — repeated in the setup skill so agents do not improvise broader scopes.

Plugin UX for producers: connection status, demo vs live store, prepare/insert that lands components with bindings visible — not a JSON console dressed up as “simple.”

Demo store must never touch a merchant catalog; live connect must fail loudly on bad tokens. Empty catalog after connect, preview conflicts when rows drifted, and half-connected states are first-class — not silent success.

Bouguessa taught me how Shopify ops actually behaves — campaigns, variants, checkout reality — even though Shop Canvas targets Framer, not Liquid themes. I did not invent a pilot customer list for this page; the collaboration beat I can stand behind is the setup skill as a contract with future collaborators and agents.

The skill documents two connections (Framer project authorisation and Shopify inside the plugin) so a coding agent does not “helpfully” skip the human step where credentials attach. Same discipline I use on client stacks: legible boundaries for the next person — or model — who touches the repo.

Shop Canvas is live — product story, component reference, plugin flow. The implementation is open at View repo. Evidence today is architectural: owned CMS sync, preview gate, component kit, and checkout handoff to Shopify — the same ownership split Bouguessa needed, packaged for Framer buyers.

I am not claiming revenue, App Store or marketplace approval, or conversion lifts. Those gates are still ahead. What a hiring reader can inspect is the system and the judgments above.

Founder work forced me to name tradeoffs I could hand-wave on client engagements: who owns the collection, what happens on a bad sync, where PCI scope stops. Shop Canvas is smaller than an enterprise design system, but the design-engineering bar is the same — make the happy path obvious and the failure paths honest.

If I were joining a team tomorrow, this is the story I’d tell: I saw a repeated commerce + design split, killed the usual bridges for good reasons, shipped infrastructure I’d want to buy, and stayed honest about what is not proven yet.