A practical look at the signals, the open-source alternatives, and the real cost of switching.
Shopify makes launching an online store remarkably easy. For most B2C retailers, it is the right choice, and many will never need anything else.
But some businesses outgrow the simple version of the problem. They expand into new markets, add B2B sales, negotiate customer-specific pricing, and connect the store to ERP, CRM and inventory systems. At that point, the team spends more time working around the platform than building on it.
If that sounds familiar, the question is not whether Shopify is good. It is whether it is still the right foundation for where your business is heading.
At a Glance
- The warning signs that a commerce platform is becoming a constraint
- Nine open-source alternatives, from established platforms like Magento and WooCommerce to API-first options like Saleor, Vendure and Medusa, and what each is suited for
- The real economics of switching, because open-source is not automatically cheaper
The goal is not to argue that open-source beats Shopify. It is to help you decide when flexibility and control are worth more than convenience.
1. Shopify: an excellent starting point, but not always the destination
There is a reason Shopify is one of the most popular e-commerce platforms in the world. Managed infrastructure, built-in payments, a large app ecosystem and simple administration let businesses start selling quickly. For conventional B2C retail, that is a strong proposition.
Shopify has also moved well beyond its basic plans. Shopify Plus offers B2B features, multiple markets, checkout extensibility and automation tools, and its Storefront API supports headless builds. Many businesses that assume they have outgrown Shopify have simply not explored these options.
Consider a business that expands into several markets, introduces B2B sales, and integrates with an enterprise ERP. Its requirements might now include:
- Customer-specific pricing and catalogues (a distributor with dozens of negotiated price lists, for example)
- Complex promotions and loyalty programmes
- Multi-level order approval workflows
- Integration with ERP, CRM and inventory systems
- Multiple storefronts and sales channels
- Custom fulfilment and inventory workflows
- Greater control over the underlying commerce architecture
Shopify can address many of these through APIs, custom apps and extensions. The difficulty is that the cost and complexity of building and maintaining those solutions can grow quickly.
So the question is no longer whether Shopify supports a feature. It is whether its architecture and extension model are the right foundation for the business’s future requirements.
2. The traditional open-source alternatives
Before API-first platforms emerged, open-source commerce was already well established. These platforms bundle the storefront, admin and commerce engine in one application, which makes them easier to start with, though less flexible architecturally than the headless options in the next section.
They also differ a lot in how much complexity they can handle, so for each one I’ve noted where it fits and where it doesn’t.
Magento Open Source
Magento has long been the reference point for open-source enterprise commerce. Its strengths are catalogue management, configurable products, promotions and a deep module ecosystem. That flexibility comes with a heavy operational load: development, hosting, upgrades and security all need real expertise.
- Best for: Businesses with complex catalogues and pricing rules, and a dedicated development team or agency.
- Avoid if: You have a small technical team or want low maintenance. Existing Magento stores also don’t need to migrate just to adopt something newer.
Bagisto
Built on Laravel, Bagisto covers the core commerce essentials: catalogue, inventory, orders, customers, marketing and multiple storefronts. It also offers extensions for B2B and multi-vendor marketplaces.
- Best for: Teams already working in Laravel and PHP who want a modular platform they can extend with familiar tools.
- Avoid if: You need a large ecosystem of ready-made integrations or a long track record at enterprise scale. Its community is smaller than Magento’s.
PrestaShop
PrestaShop is an established platform with a broad set of store management features and a large module and theme marketplace. Its newer versions are moving to a more modern Symfony foundation.
- Best for: Traditional retail, particularly multi-language and multi-country stores, where an out-of-the-box feature set matters more than architectural flexibility.
- Avoid if: You expect heavy customisation or deep ERP integration. Module quality also varies, so vet extensions carefully.
OpenCart
OpenCart covers the essentials, including products, orders, customers, extensions and reporting, with simple administration.
- Best for: Straightforward online retail where simplicity and a quick setup matter more than extensibility.
- Avoid if: You need complex B2B workflows, custom pricing logic or sophisticated backend integrations.
WooCommerce
WooCommerce is the most widely used open-source commerce option. It is a plugin on top of WordPress, which gives it a vast ecosystem of extensions, developers and hosting choices.
- Best for: Content-led businesses and teams already comfortable with WordPress.
- Avoid if: You need complex catalogues or high performance at scale. Critical features often end up spread across many plugins, which recreates the “app dependency” problem described in Section 5.
Which of these suit a business outgrowing Shopify?
Not all of them. OpenCart and PrestaShop tend to suit businesses with simpler needs, so they are rarely a natural step up from Shopify. Magento and Bagisto are the stronger candidates when B2B, complex pricing or deep integrations are the driver, and each demands more engineering capability than Shopify does.
The common thread is that traditional open-source gives you control, but you take on responsibility for hosting, security and upgrades.
3. The evolution towards API-first and composable commerce
A different architectural approach has been gaining momentum. Instead of tightly coupling the storefront, administration and commerce engine, API-first platforms expose commerce functionality through APIs. Businesses can then build custom storefronts, mobile apps and other experiences with their preferred technologies, and connect commerce to other systems more independently.
In business terms, this matters when you need to deliver commerce through several channels (web, mobile, B2B portals, marketplaces, in-store) from a single backend, or when your storefront needs to differ significantly from what a standard theme allows.
Saleor
Saleor is an API-first platform built around GraphQL and Python. It provides core commerce functionality through APIs, so developers can build custom storefronts and integrate external services.
- Best for: Teams that want a headless approach and are comfortable with Python and GraphQL.
- Avoid if: You want a ready-made storefront and admin experience with minimal development.
Vendure
Vendure is built on TypeScript, NestJS and GraphQL. Its plugin-oriented architecture lets developers customise business logic, extend entities and add specialised workflows without modifying the core.
- Best for: Organisations with existing JavaScript and Node.js engineering skills.
- Avoid if: You lack in-house TypeScript capability or need a large marketplace of pre-built extensions.
Shopware
Shopware sits between established and composable commerce. Built on Symfony and PHP, it combines traditional commerce capabilities with an API-first architecture, extensibility and headless support. It is not new, but its API-first direction is what places it here.
- Best for: Businesses that need a mature commerce foundation while moving gradually towards more flexible digital experiences.
- Avoid if: You want a purely headless, minimal core, or your team has no PHP and Symfony experience.
Medusa
Medusa is built on JavaScript and TypeScript and takes a modular approach. Independent modules, workflows and customisation points let developers extend and compose commerce capabilities rather than treating them as one inseparable application. That makes it a good fit for building specialised modules for pricing, loyalty, promotions and similar needs on a common foundation.
- Best for: Teams that prefer a modern JavaScript ecosystem and want to compose their own commerce capabilities.
- Avoid if: You need a long-established platform with a mature ecosystem of integrations and agencies.
The trade-offs of going headless
Headless is not free. You build and maintain the storefront yourself, give up much of the theme and app ecosystem that makes Shopify fast to launch, and take on responsibility for performance and SEO. Younger projects also tend to have smaller communities, fewer integrations and a smaller pool of experienced developers to hire. Check each project’s licence and commercial model as well, since these vary.
4. Understanding the differences: not all open-source platforms solve the same problem
It is tempting to compare platforms on feature lists. Architecture, extensibility and team capability matter just as much.
| Platform | Technology | Approach | Best for | Team needed |
|---|---|---|---|---|
Magento Open Source | PHP | Mature, extensible, all-in-one
| Complex catalogues and pricing | Dedicated PHP team or agency |
Bagisto | Laravel / PHP | Modular, traditional | Laravel teams, B2B and marketplace needs
| Laravel developers |
PrestaShop | Symfony / PHP | Established retail commerce | Multi-language retai | PHP developers or agency |
OpenCart | PHP | Traditional retail | Simple stores | Minimal |
WooCommerce | PHP / WordPress | Plugin-based commerce | Content-led stores | WordPress developers |
Saleor | Python / GraphQL | API-first, headless | Custom multi-channel experiences | Python and frontend engineers |
Vendure | TypeScript / NestJS | Extensible, headless | Node.js teams | TypeScript engineers |
Shopware | Symfony / PHP | Modular, API-first | Gradual move to headless | PHP and Symfony developers |
Medusa | TypeScript / Node.js | Modular, API-first | Composing custom capabilities | TypeScript engineers |
Two distinctions matter more than any column in the table.
Open-source does not automatically mean modern architecture. Several traditional platforms are open-source but still couple the storefront and commerce engine tightly.
Headless does not automatically mean composable. Headless means the frontend is separate from the backend. Composable means the commerce capabilities themselves (pricing, promotions, inventory, checkout) are independent modules that can be swapped or extended. A platform can be headless without being truly composable.
The right choice depends on the complexity of the business, the capabilities of its engineering team and its long-term technology strategy.
5. When does Shopify actually become a bottleneck?
There is no revenue threshold or order volume at which a business should automatically leave Shopify. Look instead for a combination of signals, and try to measure them:
- Increasing customisation effort: A growing share of development time goes on working around platform constraints. As a rough rule of thumb, if workarounds take up a large part of your sprint capacity, it is worth investigating.
- Application dependencies: Critical capabilities are spread across several third-party apps, increasing integration and maintenance complexity. Count how many apps sit on your critical paths.
- Complex enterprise integrations: The commerce platform must work closely with ERP, CRM and warehouse systems, and the integrations keep breaking or growing.
- Operational compromises: Business teams adapt their processes to fit the platform instead of designing workflows around real requirements.
- Rising total cost of ownership: Subscriptions, app fees, custom development and integration upkeep add up to more than the value delivered.
- Need for technology ownership: The business wants more control over its commerce engine, infrastructure and application-level customisation.
These are signals to reassess, not automatic reasons to migrate. Before moving, it is worth testing whether Shopify Plus, custom apps or middleware can solve the problem at a lower cost and risk than a full replatform.
6. The economics of moving to open-source
A common assumption is that open-source commerce reduces technology costs. That is not necessarily true.
With SaaS platforms, you pay for managed infrastructure and platform capabilities. With self-hosted open-source, you take on infrastructure, security, upgrades, monitoring, performance and maintenance yourself. Development costs also vary widely with the platform and the extent of customisation.
A proper comparison looks at total cost of ownership on both sides.
Costs on the open-source side:
- Platform and licensing costs
- Hosting and infrastructure
- Development and customisation
- Third-party extensions and services
- Integration maintenance
- Security, compliance and upgrades
- Engineers to hire or retain
Costs that are easy to miss:
- Migration itself: data, URLs, customers, order history and integrations
- SEO and traffic risk during replatforming
- Downtime and launch risk
- Opportunity cost: engineering time spent on the platform rather than on the product
Costs on the Shopify side: subscription or Plus pricing, transaction fees, app subscriptions and the development cost of working around limitations.
For some businesses, Shopify remains more economical even at considerable scale. For others, owning more of the commerce architecture delivers better long-term value. The decision should rest on your actual numbers, not on the assumption that open-source is always cheaper.
7. Is it time to rethink your commerce architecture?
Commerce is no longer just a website where customers browse and buy. It increasingly spans customer engagement, inventory, fulfilment, payments, pricing, loyalty, analytics and enterprise operations, all of which must work together.
AI adds another dimension. Personalised recommendations, dynamic promotions, customer segmentation and automated workflows all depend on two things: clean, accessible data, and the ability to plug new capabilities into the commerce flow. Platforms with open APIs and modular extension points make that easier, though they do not make it automatic. Shopify’s own APIs and ecosystem support many of these use cases too, so the question is how much control you need over the data and logic behind them.
As these requirements grow, the ability to customize and integrate commerce capabilities becomes more important. But flexibility brings responsibility. The challenge is finding the right balance between managed convenience and architectural control.
Conclusion
Shopify has earned its position by making e-commerce accessible to businesses of every size, and for many it remains an excellent choice. As operations grow more sophisticated, though, it is worth reassessing periodically whether your platform still fits.
The open-source ecosystem offers several routes: established platforms such as Magento, Bagisto, PrestaShop, OpenCart and WooCommerce, and API-first platforms such as Saleor, Vendure, Shopware and Medusa. Each represents a different approach to building and managing commerce.
The question is not whether open-source is better than Shopify. It is when your need for flexibility, control and customisation outweighs the convenience of a managed platform.
A quick self-check. If you can answer yes to several of these, it is worth exploring alternatives:
- Is a significant share of your development effort spent working around the platform?
- Do critical capabilities depend on a growing stack of third-party apps?
- Do your ERP, CRM or warehouse integrations need deeper control than the platform allows?
- Are your teams changing their processes to fit the platform?
- Do you have, or can you hire, the engineering capability to own a commerce stack?
- Does the total cost of your current setup exceed the likely cost of owning your own?
That tipping point will be different for every business, and understanding it could be one of the more important technology decisions an evolving e-commerce business makes.
Option 2: Platform Limitations
Ahamed Sajid is a technology delivery leader focused on building scalable systems that bridge business strategy and execution. With experience across fintech, mobility, e-commerce and enterprise platforms, he specializes in designing structured approaches to complex problem-solving and product delivery. He is particularly interested in how well-defined systems, processes, and technology frameworks can drive sustainable growth and operational clarity. Through his work, Ahamed advocates for pragmatic innovation where ideas are shaped into reliable, high-impact solutions that deliver real-world value.
