Shopify, Magento, and WooCommerce will take a retailer a very long way. They handle the storefront, the checkout, the payment edge cases, and a thousand problems you would otherwise pay to discover yourself. For most stores, reaching for custom software is a mistake. But there is a point — different for every business — where the platform stops being the thing that lets you move fast and becomes the thing you are constantly working around. Knowing where that line sits, and what to do when you cross it, matters more than any framework you might pick.
The platform ceiling is real, and it is not about size
The instinct is to assume you outgrow a platform when you get big. In practice the ceiling has little to do with order volume and everything to do with how unusual your business is. A store with modest revenue but a genuinely complex catalog — configurable products, bundles that draw stock from several SKUs, units of measure that are not simply 'one item' — hits the wall long before a high-volume shop selling a handful of simple products ever will.
B2B pricing is where this shows up most sharply. The moment different customers see different prices — contract rates, volume tiers, per-account catalogs, quotes that turn into orders — you are asking a platform built for one public price to do something it was not designed for. The same is true of anything involving stock across locations, or a checkout that has to respect credit limits and payment terms rather than just taking a card.
The signs are consistent. You maintain a growing stack of apps that each half-solve the same problem. Your team exports to spreadsheets to answer questions the admin cannot. A change the business thinks is small takes weeks because it fights the platform's assumptions. None of these is fatal alone. Together they are the platform telling you your requirements have moved past what it was built for.
Headless commerce: separate the storefront from the engine
The first custom step is usually not a rebuild — it is a separation. Headless commerce means the customer-facing storefront becomes its own application, talking to the commerce platform through its API rather than living inside its templates. You keep the platform for what it is good at — the catalog, the cart, payments — and you own the experience layer on top.
This buys you two things that matter. You can build a storefront that is genuinely yours — fast, distinctive, tuned to how your customers actually shop — instead of fighting a theme engine. And you can put the same commerce engine behind more than one front end: a website, a mobile app, an in-store kiosk, a partner portal. Headless is not free — you now own code you previously rented — so it is worth doing when the experience is a real differentiator, not when a good theme would have done the job.
There is a middle path worth knowing about. You do not have to go fully headless to escape the theme engine — many platforms let you replace only the most important pages, or run a custom storefront for one market and the standard one everywhere else. The point of headless is not architectural purity; it is owning the parts of the experience that decide whether a customer buys, and renting the rest. Draw that line deliberately, because every page you take ownership of is a page you now have to maintain.
The real backbone is order and inventory management
Storefronts get the attention because customers see them. The system that actually decides whether a growing retailer sinks or swims is the one nobody sees: order and inventory management. The storefront takes an order in ten seconds; fulfilling it correctly, from the right location, with accurate stock, across every channel, is where the real complexity lives — and where an off-the-shelf platform's built-in tools tend to give out first.
An order management system (OMS) is the single place that knows what a customer ordered, what you actually have, where it is, and what happens next. It routes each order to the right warehouse or store, holds and releases stock so you do not oversell, handles partial shipments, backorders, returns and exchanges, and keeps one honest number for available inventory across the whole business. When retailers tell us the platform is failing them, this is almost always the layer that is actually broken — not the shop, the plumbing behind it.
The reason this layer gives out first is that platforms model inventory as a number attached to a product, while a real business needs inventory modelled as stock in places, with commitments held against it. Once you sell from more than one location, promise delivery dates, or reserve stock for a channel, a single number stops being enough. The spreadsheets and manual checks people build to cope with that gap are usually the first honest sign that an OMS is overdue.
One customer, many channels
Omnichannel is an overused word for a simple, hard idea: the same customer should be recognisable, and your stock should be truthful, whether they buy online, in a store, or through a marketplace. In reality most retailers run these as three disconnected systems — the website has its stock, the point of sale has its own, and the marketplace listing lags behind both. The result is the thing every retailer fears: selling something you cannot ship.
Custom software earns its place here by making inventory a shared source of truth rather than three copies that drift. The point of sale, the online store, and the marketplace feed and read from the same stock and order records, so a sale in a shop updates what the website can promise, and a return online is visible at the counter. This is rarely a single product you can buy; it is integration work that has to fit your specific mix of channels — and it is usually where a custom project pays for itself fastest.
ERP and fulfilment: the integrations that decide the project
Behind the shop sits the rest of the business — the ERP or accounting system, the warehouse, the couriers, the suppliers. A retail software project succeeds or fails on how cleanly it talks to these, far more than on any feature in the storefront. An order that reaches the website but never reaches finance, or stock that is right in the warehouse and wrong online, undoes everything the nice storefront achieved.
Treat integrations as first-class scope, not an afterthought. Each connection needs a deliberate decision about which system owns which data, how often they sync, and what happens when one is down. The honest version of this work is unglamorous: mapping fields, handling failures, reconciling numbers nobody wants to reconcile. It is also where most of the risk and most of the value sit, so it deserves the most careful thought at the start, not the least.
When custom pays off — and when the platform is still right
Custom software pays off when your process is a genuine differentiator, when the workarounds have a measurable cost — hours lost, orders mis-shipped, growth you cannot take on — and when a capability is central enough that owning it is worth the responsibility. If your catalog, pricing, or fulfilment is genuinely unlike your competitors', that difference is an asset worth building around.
The platform is still right more often than vendors admit. If your requirements are ordinary, if an app or a theme change would solve the problem, or if the pain is real but small, custom software is an expensive answer to a cheap question. The best retail teams we work with are ruthless about this line: they buy everything they can and build only what genuinely sets them apart. Custom is a tool for the parts that make you different, not a badge of seriousness.
A useful test is to ask what happens if you do nothing. If the workarounds are irritating but stable, the platform is still right and custom software is a want rather than a need. If they are getting worse as you grow — more manual steps, more errors, more orders or revenue you have to turn away — then the cost of not building is compounding, and that is the honest trigger to act. The question is never whether custom software is impressive; it is whether the pain is growing faster than the platform can absorb it.
Extend before you replace
The safest path is almost never a rebuild. It is to extend the platform you have — add a headless storefront, or an OMS, or a marketplace integration, alongside it — and let the platform keep doing the job it does well. You replace a piece only once its custom successor is proven in production, and you keep the parts that were never the problem. That way the business keeps running the entire time, and each step earns its cost before the next one starts.
Which piece to build first, and whether to build at all, is not a decision to make from a feature list. It comes from an honest look at where your specific stack is actually hurting — which is exactly what a short assessment is for.