One of my clients built a furniture brand on Shopify and grew it to $4M annual revenue. At that point, they hit a wall. Not a traffic wall, not a marketing wall. A platform wall.
They wanted to sell through their own showrooms as well as online, with unified inventory. They wanted B2B ordering with net-30 terms for interior designers. They wanted a product configurator where customers could customize dimensions and finishes and see a real-time price. And they wanted to expand internationally with region-specific pricing and fulfillment.
Shopify could do some of this. Not all of it, and not in a way that would work as a unified system. The conversation I had with them was the one I have had with dozens of e-commerce companies at a similar stage: you have not outgrown e-commerce, you have outgrown a platform that was designed for something simpler than what you are now building.
We made the transition over five months. Today they run a custom ecommerce architecture - headless commerce with unified inventory across seven locations, a B2B portal, and sales in four countries. This is the kind of fractional CTO ecommerce engagement that only makes sense after a business has outgrown its platform.
When to Stay on Shopify and When to Leave
Most e-commerce startups should stay on Shopify longer than they think. It is not a beginner platform - it is a professional platform that handles an enormous amount of complexity behind the scenes. Payment processing, fraud detection, hosting, security, checkout UX, mobile optimization, SEO - all handled.
The cost of leaving is real. Custom infrastructure requires engineers. Every feature you relied on Shopify for needs to be built or bought. The operational overhead is significant. I have seen founders dramatically underestimate the cost of going custom.
The cases where leaving Shopify is the right call:
You need inventory management that Shopify cannot support. This usually means omnichannel (online + physical retail with shared stock), B2B with complex pricing rules, or manufacturing with production-based inventory. Shopify's inventory model is straightforward; these cases are not.
You need a checkout experience that Shopify does not allow. Shopify controls the checkout flow and limits what you can customize. If your product requires a multi-step configurator before add-to-cart, a rental or subscription model with complex terms, or a quote-request flow instead of an immediate purchase, you will hit the platform walls.
Your product catalog has complexity that does not map to Shopify's data model. Shopify's variant system supports up to 100 variants per product. If you are selling clothing with more combinations than that, or configurable products with conditional options, the data model breaks.
You need deep integration with systems Shopify does not connect to well. ERPs, custom warehousing systems, specialized shipping carriers.
Below $2M in revenue, almost every e-commerce business should be on Shopify or another hosted platform. Above $5M with significant architectural constraints, custom is often necessary. Between those numbers, it depends on the specific limitations you are hitting.
Headless Commerce: What It Actually Means
"Headless commerce" is a term that gets used a lot and understood less. The simple version: your frontend (the website, mobile app, kiosk) is decoupled from your backend (inventory, pricing, checkout, order management). They communicate through APIs.
The "head" in headless is the frontend. In traditional Shopify, the frontend is Shopify's Liquid template engine - the head is attached to the body. In headless, you build your own frontend using whatever technology you want, and it talks to a commerce backend through APIs.
The advantages: complete control over the frontend experience, the ability to use modern frontend frameworks, performance advantages for complex UIs, and the ability to deliver the same commerce capabilities across multiple frontends (web, mobile, in-store kiosk, voice).
The disadvantages: you are responsible for the frontend, which is expensive to build and maintain. You lose a lot of the out-of-the-box Shopify functionality that handles things like SEO optimization, mobile responsiveness, and checkout UX. These things are not hard to build - they are just not free anymore.
The practical guide for the headless decision: do not go headless to be modern. Go headless because you have a specific frontend requirement that a hosted platform cannot meet. The ROI on headless commerce is real when the requirement is real. It is negative when the driver is architecture fashion.
Inventory System Architecture: The Part That Is Harder Than It Looks
Inventory management is where e-commerce architecture gets genuinely complicated. The simple model - a number that decrements when you sell something and increments when you receive stock - works until you have multiple warehouses, backorders, pre-orders, B2B with reserved inventory, or any complexity in how products are assembled or fulfilled.
The problems I see most often:
Overselling. Two customers place orders simultaneously for the last item in stock. Both orders succeed. Now you have an inventory problem. The fix is either database-level locking (prevents the second order from completing) or reservation-based inventory (the first cart to reserve the item holds it for a window). Both require explicit design.
Multi-warehouse fulfillment routing. You have warehouses on both coasts. An order comes in from Chicago. Which warehouse fulfills it? The answer depends on stock levels, shipping cost, and delivery time commitment. This logic needs to be explicit and configurable.
Backorder and pre-order management. When an item is out of stock, do you allow orders and fulfill when it comes in? If so, how do you communicate lead times? How do you handle partial shipments if other items in the order are in stock? These are business rules that need to be implemented in the inventory system.
The inventory system is the core of an e-commerce business. It is also the hardest part to rebuild if the initial design is wrong. Investing in a proper inventory data model and the business rules around it early is one of the highest-ROI technical decisions in an e-commerce build.
International Commerce: More Complex Than Adding a Currency
Expanding internationally is a common inflection point for e-commerce businesses, and it is reliably underestimated as a technical challenge.
The layers of complexity:
Currency and pricing. Displaying prices in local currency is the simple part. Supporting local pricing (where the price in euros is not just the dollar price converted, but a market-specific price) requires a pricing model that supports multiple price lists. Shopify Markets handles some of this; a custom system needs to implement it explicitly.
Tax and compliance. VAT in Europe, GST in Australia and Canada, consumption taxes in various Asian markets. The rules vary by country, by product category, and (in the US) by state. Tax calculation services like Avalara or TaxJar handle the complexity, but they need to be integrated into the checkout flow correctly.
Fulfillment and shipping. International shipping is expensive and has its own compliance requirements (customs documentation, restricted product categories). You need relationships with international carriers and a system that can generate appropriate customs documentation automatically.
Localization. Not just currency and language, but payment methods (credit card penetration varies dramatically by country), checkout expectations (some markets expect installment payment options as standard), and customer service contact expectations.
I typically advise e-commerce companies to treat international expansion as a major infrastructure project, not a feature release. Budget six to twelve weeks of engineering work for each major new market, depending on your current infrastructure.
The Technical Interview Every E-Commerce Founder Should Be Able to Answer
Before you go custom, before you choose a platform, before you hire your first engineer - there are five questions I ask every e-commerce founder:
What is your product complexity? How many SKUs, how many variants, do you have configurable products, do you have bundle or kit products?
What is your fulfillment model? Single warehouse? Drop-ship? 3PL? Omnichannel? Your inventory architecture depends almost entirely on this answer.
What is your customer model? B2C only, or do you have B2B customers with custom pricing? Do you have subscriptions or recurring orders?
What are your integration requirements? Which ERP, which accounting system, which warehouse management system, which shipping carriers?
What does your growth look like? Are you planning international expansion? Physical retail? New product lines that have different fulfillment requirements?
The answers to these questions determine the architecture. Most of the expensive mistakes I have seen in e-commerce - the ones that require six-month rebuilds - came from starting with a platform or a custom architecture that did not match the actual business requirements.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr