Case
studies.
The hard problems behind the storefronts and marketplaces: what broke, how we approached it, and what we built.
Work that goes past the theme
Most Shopify projects are a theme, a few apps and a launch. These case studies cover the other kind: the requirements the platform doesn't handle out of the box, where the answer is custom logic, not another app from the store.
Each one follows the same structure. We describe the client's problem in plain language, explain the approach and the trade-offs we weighed, walk through what we built, and list the technology behind it. The clients are unnamed, but the problems are real and the solutions are running in production.
Two projects came from a performance automotive parts retailer moving from WooCommerce to Shopify. Three more came from a storage and parking rental marketplace that needed monthly subscriptions, liability waivers and sales tax its platform didn't offer out of the box. Together they show how we work across custom Shopify apps, theme development, platform migration and custom marketplace development.
Configurable kits and bundles
A kit of forty parts should look like one product in the cart and one line on the packing slip, while every part stays a real line item for inventory, fulfillment and returns. We used a Cart Transform built on Shopify Functions, plus a kit-aware order editor built with Admin UI extensions so staff can change placed orders safely. Read the kits case study.
Multiple brands, one store
Two Shopify stores mean two admins, two catalogs and two checkouts. We kept one store and made the theme brand-aware: product pages take their brand from the vendor field, other pages from a simple admin setting, with a safe default when nothing is set. Read the multi-brand case study.
Moving from WooCommerce
Both projects were part of a migration from WooCommerce to Shopify, which is when these gaps usually surface. Features that were custom code on the old platform need a Shopify-native answer, and order history has to come across too. See how we plan a Shopify migration.
Sharetribe customization
Sharetribe is good at one-off bookings and short on everything a long rental needs: recurring billing, signed waivers, multi-state sales tax. We built all three with custom transaction processes, the Integration API and Stripe, keeping the marketplace in charge of the rental and Stripe in charge of the money. Read the subscriptions, waivers and sales tax case studies.
Payments that have to stay in step
Subscriptions, holds, refunds and tax all mean two systems keeping their own record of the same rental, for years. We design every money step to be safe to run twice, so a duplicate click or a repeated webhook never charges someone a second time, and a failed renewal recovers on its own.
Map the whole lifecycle, then build
We start by tracing an order from the cart to the warehouse and back again: bought, edited, picked, invoiced, cancelled and returned. On the marketplace side it's the same habit applied to a rental: requested, approved or declined, renewed, overdue, recovered, cancelled and expired. A fix that works at checkout but breaks a return, or a twelfth renewal, isn't a fix.
We prefer to keep the platform's own data intact and change only what people see, so inventory, reports and other apps keep working. We put day-to-day settings in Shopify admin or the theme editor, so the client's team can run the result without a developer. When a client wants to try a riskier route, we write up the trade-offs first so the decision is made on paper, not in production.
The person who scopes the work is the person who builds it. If your store has a problem like this, tell us what's breaking or browse the Shopify stores we've worked on.
Got a problem your platform doesn't solve out of the box?
Tell us what's breaking and we'll come back with how we'd approach it. Free, no pitch attached.