Shopify Development and Integration for Content-Led Commerce
The store is the easy part. Everything it has to talk to is not.
Shopify runs the catalog, the cart and the checkout, and runs them well enough that the storefront is rarely the hard part of the project. The hard part is either side of it — the content that does the selling, the system of record the order has to agree with, and the pricing rules that are specific to who is buying.
Shopify is the commerce engine: hosted catalog, cart and checkout, the most heavily tested checkout on the web, and tax, shipping and fulfilment behind it. The mistake in an institutional build is treating the storefront as the site. Shopify is excellent at the transaction, and a considered purchase also turns on the explanation, the specification, the comparison, the accreditation and the reason a member price exists — material written by people who do not work in a commerce admin, living in a content platform, and the reason the visitor is on the page at all. Run the whole experience inside Shopify and the editorial work gets done badly by a team fighting the wrong tool. Stand commerce up beside the site instead and the catalog is maintained twice and disagrees with itself by the end of the quarter. What works is Shopify as the commerce engine behind the platform you already run. One catalog, one system of record, content authored where it is authored and product data read at request time. That is an integration problem, and integration problems are decided by how they fail.
Our Work with Shopify
How the Work Splits
Hosted catalog, cart and checkout with PCI compliance and fraud tooling maintained for you; the most heavily tested checkout on the web, with Shop Pay and an accelerated payment set behind it; tax, shipping and fulfilment logic; a Storefront API and Hydrogen for headless builds; and an app ecosystem covering subscriptions, memberships, loyalty and B2B price lists.
The judgment about where the line falls — what belongs in Shopify, what belongs in the content platform and what is authored once and read by both; catalog and content modelling that survives a second brand, a second country or a member tier arriving later; integration to the system of record so an order, a member record and a price agree; theme or Hydrogen work built against WCAG rather than scanned for it before launch; and instrumentation that measures the purchase rather than the pageview.
Commerce as a component of the platform rather than a second website. The catalog is maintained once, the editorial work happens where the editors already are, the checkout is the one Shopify has spent a decade tuning, and the accessibility, performance and measurement standards are the ones the rest of the platform is already held to.
The work in practice
Shopify is the platform most likely to arrive already decided. Someone in the organization has a store on it, or a colleague at another institution does, and the question by the time it reaches us is not whether to use it. The question is what else it has to touch, and that is where these projects are won or lost.
Decide where the line falls, then hold it
Every Shopify build makes one architectural decision and lives with it for years: which system owns which fact. Product identity, price, inventory and the order belong to Shopify, because it is the thing that will be audited and the thing that takes the money. Explanation, specification, accreditation, guidance and every word a buyer reads before they are a buyer belong to the content platform, because they are written by editors, reviewed by people with a compliance interest, and translated on the same pipeline as the rest of the site.
The failure mode is not choosing. A catalog description gets pasted into Shopify because it was faster that week, and eighteen months later two systems hold two versions of the same sentence and no one can say which one is current. The fix is boring and has to be made on day one: one owner per fact, read at request time by whatever else needs it.
The integration is the engagement
A storefront that only has to sell to anyone is a weekend. The work is the qualifiers — a member price that depends on a record in an association management system, an institutional purchase order that is not a credit card, a tax treatment that changes with what is being sold and to whom, a fulfilment vendor with its own idea of what an order looks like.
So the interesting decisions are about failure. An inventory call that times out has to degrade to a page that still sells rather than a page that returns a 500. A membership lookup that cannot reach its system of record has to fall back to list price and say so, not silently charge the wrong one. A webhook that fires twice has to produce one order. None of that is visible in a demo and all of it is what running a store feels like.
Accessibility is a build decision here too
A commerce theme is bought, and what is bought is markup no one at the institution controls — which means accessibility becomes something you can test and never assert. It matters more in a checkout than almost anywhere else on a site, because the consequence of an unlabelled field is not a poor experience but an abandoned purchase by someone who was ready to buy. Building the components against the standard, whether in a theme or in Hydrogen, makes the claim a property of the system.
When the job is bigger than the store
The test is whether the hard part is the transaction or everything that has to be true before it. A multi-country storefront with six languages, country-specific pricing and a product education job larger than the transaction is a platform build with commerce in it — the shape of the Leica Geosystems build, one Drupal Commerce platform running several country stores over a single catalog and splitting the experience by buyer intent. For that shape, we match the engagement to the platform built for it.