Don't rebuild the cart: commerce as the start of the pipeline
Keep checkout on Shopify and spend the build budget on what actually differentiates the business — content before the cart, or operations after the order. Provale Cup is mostly clinician-facing content on Next.js and Sanity; Al's Flowers is mostly ticket generation and print once an order lands. Both look like commerce projects. Neither is primarily about rebuilding the cart.
Checkout is the one part worth not building
A checkout that works is not a form. It is sales tax across jurisdictions, address validation, payment method coverage, 3DS, fraud scoring, chargeback handling, PCI scope, and a decade of small fixes for the ways real people actually pay for things. All of that is solved, hosted, and maintained by companies whose entire business is keeping it working.
The argument for rebuilding it is usually design: the hosted checkout does not match the site. That is a real cost, and it is smaller than it feels. The customer is on the checkout page for under a minute, they expect it to look like a payment step, and a visually consistent checkout that mishandles a Louisiana parish tax rate is worse than a slightly off-brand one that does not.
So the default we bring to commerce work is that the platform owns the cart, the checkout, the payment, and the canonical order record. We own everything on either side of it. That is not a constraint on the build. It is what frees the budget for the parts that are actually specific to the business.
Provale Cup: everything except checkout is content
Provale Cup sells a metered drinking cup for people with dysphagia. The buyer is often a speech-language pathologist, an occupational therapist, or a family member who has just been handed a diagnosis. The purchase decision is not made on a product page. It is made after reading about swallowing safety, seeing how the cup meters a sip, and learning that clinicians use it.
So the build is a Next.js front end on Sanity, with a clinician resource library and marketing pages that are editor-owned end to end. Every page is a singleton with grouped fields, which means the team can change how the product is explained without a deploy. For a regulated medical device that is not a small thing, because the way you describe the product is subject to review and it does change.
The commerce surface is thin by comparison: product presentation, then a handoff to Shopify checkout. That ratio is the point. Engineering effort went where the business is actually differentiated, and the part that is identical to every other store on the internet was bought rather than built.
- PCI scope becomes yours
- Tax rules in every jurisdiction
- Fraud and chargeback handling
- A payments outage is your outage
- Compliance surface stays theirs
- Tax and fraud already solved
- You own content and the funnel
- Less of the site you have to defend
Owning the whole experience sounds like control. Mostly it's acquiring a compliance surface you didn't want.
Al's Flowers: the order is the start of the work
A florist's problem is not taking the order. It is that a placed order has to become a physical arrangement, made by a specific person, delivered to an address inside a window, or held for pickup. Shopify knows an order exists. It does not know that the designer in the back needs a piece of paper in front of them.
So orders arrive by webhook and get ingested into MongoDB, where they become operational records rather than sales records, carrying the fields the shop actually works from. From there the system generates delivery and pickup tickets as PDFs, and PrintNode pushes them to a printer in the workroom. An order placed online produces a ticket on the bench without anybody in the shop opening a browser.
That is the whole shape of the project, and none of it is commerce in the checkout sense. Shopify is the front door. The build is the hallway behind it.
Where to put the seam
In both projects the seam sits in the same place. Shopify owns money and the canonical order. We own presentation before it and operations after it. Drawing the line there keeps the risky, regulated, tediously detailed parts inside a system maintained by somebody else, and keeps the parts that encode how this specific business works in code we control.
The practical rule on the webhook side is to assume the network lied. Webhooks arrive twice, arrive out of order, and occasionally do not arrive at all. Every ingest handler has to be idempotent on the order ID, and there needs to be a reconciliation path — a periodic pull that fills gaps — because a florist discovering a missing order at four in the afternoon on Valentine's Day is not a recoverable situation.
On the content side, the rule is that the store is a rendering of the catalog and not a copy of it. Prices, availability and variants come from the commerce platform at request time or through a build hook. The moment product data is maintained in two places you have a drift problem, and drift here shows up as a customer buying something at last month's price.
When building the cart is the right call
There are real cases. Subscription logic the platform does not model. B2B pricing that varies per customer account. A configurator where the product does not exist until the customer specifies it. Wholesale flows with quotes and approvals. If the commerce logic itself is the differentiated thing, then build it.
Even then the split is usually still worth keeping. Own the cart and the pricing logic, and hand the payment step to a processor's hosted flow. PCI scope is the thing you want off your plate almost regardless of how custom the rest gets.
The question to ask during scoping is simple: what about buying this is genuinely different from buying anything else? If the honest answer is nothing, then the store is a content problem and an operations problem wearing commerce clothing, and that is where the money should go.
Questions
- Why keep Shopify checkout instead of a custom cart?
- A working checkout includes tax, address validation, payment coverage, 3DS, fraud, chargebacks, and PCI scope — work platforms already maintain. A slightly off-brand hosted checkout that settles correctly usually beats a custom one that mishandles edge-case tax.
- Where should the seam sit between Shopify and custom code?
- Shopify owns money and the canonical order. Custom code owns presentation before checkout and operations after — content, fulfillment tickets, print, and shop-specific workflows. That keeps regulated payment detail off your plate while encoding how this business actually works.
- When is building a custom cart the right call?
- When buying itself is differentiated: subscription models the platform cannot express, B2B account pricing, configurators that invent the SKU, or wholesale quote-and-approve flows. Even then, hand the payment step to a hosted processor flow to keep PCI scope narrow.