A standard Shopify theme can manage a store with 40 products and three apps efficiently. For example, if you add 900 SKUs, a subscription app, a review widget, two pop-ups, and a loyalty program, the same theme begins hanging on mobile. That’s when you start saying it’s “headless”.
But these two solve two different problems, and neither one is simply the grown-up version of the other. It’s possible that a store doing $2 million a year can be perfectly happy on a traditional platform, and another store half that size might genuinely need headless because of how it sells. But for most businesses, the important question is which setup the team can actually run well for the next two or three years.
On a traditional (monolithic) platform, everything is delivered as one piece. Product catalog, checkout, admin dashboard, and the storefront shoppers browse all sit in the same system and update together. Shopify with an Online Store 2.0 theme works this way. So do WooCommerce and Adobe Commerce, which most people in the industry still just call Magento.
Headless makes the storefront and makes it its own application. The backend keeps doing the heavy lifting (inventory, orders, pricing, payments) and sends data to the frontend through APIs, usually GraphQL or REST. Developers then build the customer-facing site with a JavaScript framework like Next.js, Remix, or Nuxt and deploy it to cloud or edge hosting.
Keeping the two layers in sync takes more planning than most owners assume. Webhooks from the backend tell the frontend when a price or stock level shifted, and the frontend decides which cached pages to rebuild; get that wrong, and a jacket shows as present on the product page but fails at checkout. Discovery work from a headless commerce development company usually maps these data flows before any design starts, while the merchandising team keeps handling products in the same admin they used before. Shoppers never notice the division. They just get a site that, when it’s built well, loads noticeably quicker.
A decent comparison is a shop floor and the stockroom behind it. Traditional commerce sells you both as a fixed unit, with shelving already bolted in place. Headless leaves the stockroom alone and lets you reconstruct the shop floor however you like. You get total freedom over the layout. You also get the bill for the carpenters.
This part tends to get skipped in headless conversations, which is not good. Traditional platforms are mature, well-supported, and, for a large share of growing brands, more than enough.
Launch speed is the direct win. A two-person team can get a clean store live in three or four weeks using a paid theme from the Shopify Theme Store. Want product reviews, subscriptions, or email capture? The app store has ready-made equipment for each, and most install in minutes without a developer. When something breaks at 11 p.m., there’s documentation, a forum thread, and probably a YouTube video from someone who hit the same bug last year.
Budgeting is simpler as well. The monthly platform fee, a theme license, and a stack of app subscriptions add up (sometimes to more than owners expect), but the number is acceptable. No sprint planning. No developer retainers.
The weak spots show up gradually. Every app injects its own JavaScript, and after a dozen of them the page weight creeps up in a way that’s difficult to undo without breaking something. Custom layouts hit the limits of what theme sections let. And if the business wants to sell through a mobile app, a kiosk in a pop-up store, and a marketplace, all fed from the same product data, the single-website design starts to feel cramped.
There isn’t one moment. It’s more like a slow build of little frustrations, and a few of them show up in almost every store that finally moves to headless.
If none of these sound familiar, the store probably isn’t there yet. That’s fine.
A traditional store can go live for a few thousand dollars, or a few hundred, if the owner is handy.
Headless costs more, and the range is broad. Discovery, UX design, frontend development, API integration, QA, and launch commonly put projects somewhere between tens of thousands of dollars and well into six figures. Two to six months is quite a normal timeline for a mid-size catalog, longer if there’s an ERP or a custom pricing engine to connect.
The spending doesn’t stop at launch. Frameworks offer updates, security patches need applying, and the marketing team will need new features by the next quarter. Apps that install with one click on a traditional platform may require real integration work on a headless build. None of this is a reason to avoid headless. It just belongs in the forecast from day one, not as a surprise in month seven.
The easiest way to look at it: headless moves money away from app fees and lost conversions and puts it into engineering. Stores with little traffic see that investment come back through higher conversion and better SEO. Stores with modest traffic often don’t, at least not yet.
Often, this is the question that gets asked last, even though it decides a lot.
Marketers and merchandisers can run a traditional store with hardly any code. Headless changes that. Somebody requires to understand the frontend framework, API rate limits, caching rules and hosting configuration, and that somebody wants to be available when a product launch goes sideways on a Friday afternoon.
Companies manage this in different ways. A few already have frontend engineers on staff. Others keep an outside development team on retainer and train one internal developer to manage smaller fixes. The setup matters less than the clarity; if nobody clearly owns the storefront, small issues quietly pile up.
Workflow habits change as well. A marketing team used to installing an app on Tuesday and seeing it live on Wednesday may find the developer queue slow at the beginning. A well-configured CMS with reusable content stops closes most of that gap. Most, not all.
Enough stores never go fully headless, and they’re not doing it wrong.
A common pattern: rebuild the homepage, collection pages, and content hub as a headless frontend, but leave checkout on the platform’s native system. Shopify’s checkout converts well and manages payments and fraud screening out of the box, so many headless Shopify builds simply keep it.
Composable commerce goes a step beyond. The business chooses a separate service for each job (site search, product reviews, payments, content management) and connects them through APIs. It resembles putting together a stereo system from separate components instead of buying one all-in-one unit. More wiring. More control over each piece.
For teams that want a smoother start, Shopify Hydrogen on Oxygen hosting keeps the framework, the hosting, and the backend under one vendor. Fewer integration surprises, and a shorter learning curve for developers new to headless.
A few questions tend to settle the decision quicker than any feature comparison:
Mostly “no”? A cleaner theme, fewer apps, and some performance tuning will mostly carry the store for a good while. Several firm “yes” answers, especially on speed and channels, often mean headless is worth scoping properly.
Timing counts for a lot here. Many well-known DTC brands ran on standard themes for years and moved to headless only once revenue made the case obvious. Going headless quickly doesn’t earn any extra points.
Traditional and headless ecommerce fit various stages of a store’s life. Traditional platforms are quicker to launch, cheaper to operate, and easier for non-technical teams, which is why they suit most businesses through their early and middle growth. Headless pays off once speed, content flexibility, multiple channels, or international markets begin directly affecting revenue.
The decision rests on a handful of practical factors: current traffic and sales, the number of channels in play, the budget for ongoing work, and the people who’ll handle the storefront. Neither path locks a business in forever. A store can grow on a traditional platform, watch its numbers, and change to headless when those numbers make the move clearly worthwhile.
Ans: The top 3 eCommerce platforms are Shopify, WooCommerce, and BigCommerce.
Ans: The main disadvantages of using a headless CMS are that it doesn’t have a built-in presentation layer.
Ans: The most used headless CMS is Strapi and Contentful.
