E-commerce development
Next.js Commerce
Storefronts on Shopify, Commerce Layer, Medusa or a custom backend - built so the product page is static, the cart is not, and neither one waits for the other.
Commerce is where the Next.js rendering model earns its keep, and where
getting it wrong is most expensive. A product page that takes three seconds
does not convert, and every storefront template we have inherited made the
same architectural choice: one use client at the top, because the cart needs
state.
That decision makes the catalogue - the part that should be static, cached at the edge and indexed - as dynamic as the checkout.
How we split it
The catalogue is static. Product pages, collections and search landing pages are generated at build or revalidated by tag when the backend says something changed. They come off the CDN, they are indexable, and their LCP does not depend on your commerce API being awake.
The cart is a client island. A small component, not a boundary around the page. Quantity, mini-cart and add-to-cart are interactive; the product description, images, reviews and structured data around them are not, and stay on the server.
Prices and stock are the exception, handled deliberately. They cannot be stale, and they also cannot be allowed to make the page dynamic. Either they stream in behind Suspense while the rest of the page paints, or they are tag-revalidated on the backend's webhook. Which one depends on how often your prices actually move - we will ask rather than assume.
Checkout stays where it is. If you are on Shopify, the hosted checkout is PCI-compliant, converts well and is not worth rebuilding. We integrate up to it. A custom checkout is a project of its own and we will tell you when it is not justified.
What we do about the parts that decide revenue
Product structured data with real Offer and availability, so rich results
show a price. Correct canonicals across variant and filter URLs - a faceted
catalogue generates thousands of near-duplicate addresses, and left alone they
spend your crawl budget on parameter combinations nobody searches for.
Core Web Vitals treated as a commerce metric rather than an engineering one, measured on the templates that carry traffic, with a budget enforced in CI so the next theme change does not undo it.
Which backend
Shopify (Storefront API), Commerce Layer, Medusa, BigCommerce, or your own service. The storefront architecture is the same in each case; what differs is the data layer, and that is the part we type and cache carefully.
If you are on Shopify's own themes and considering a headless storefront, the honest answer is that it is worth it when you have a real front-end team or us, and not worth it when you do not. A Liquid theme maintained well beats a headless storefront nobody owns.