I don't actually think that the main reason to choose Drupal Commerce comes from the Drupal Commerce system itself.
That might sound like a strange thing to say at the start of an article about Drupal Commerce, but hear me out for a moment.
The real power of Drupal Commerce comes from the fact that it exists inside the Drupal ecosystem. It's built into Drupal, it follows the same architectural patterns, it uses the same entity systems, permissions, configuration management, caching layers, all of it. That means that by choosing Drupal Commerce you're not just choosing an ecommerce platform, you're choosing the entire Drupal system and everything that comes with it.
Security. Stability. Extensibility. A huge ecosystem of modules and developers who understand how the platform works. Drupal Commerce on its own is good, but Drupal Commerce inside Drupal is where things start to get interesting.
There's a lot of ecommerce platforms out there that promise to get you up and running quickly. Things like Shopify, or stores built with WordPress and WooCommerce. And to be fair, for a lot of businesses those tools do actually work pretty well.
If all you need is a catalogue of products, a checkout page and a payment gateway then these systems can get you a long way very quickly. But there is a catch. The moment you want to step outside the box that these systems were designed for, things start to get… complicated.
With platforms like Shopify it can look like you can just write custom modules or apps and extend the system however you like. On the surface that sounds very similar to how modules work in Drupal, but once you start digging into how it actually works, it becomes clear that the development model is very different.
Instead of extending the platform directly, most custom functionality ends up living in external applications that talk to Shopify through APIs and webhooks. Those applications might be written in Node, Ruby, or whatever backend stack you prefer, but they are still separate systems that have to be deployed, maintained and integrated properly.
So instead of extending the platform itself, you're effectively building a second platform that sits next to it.
Now don't get me wrong, APIs are great, but this does mean that building deep custom functionality becomes more complicated than just writing a module and plugging it into the system.
And there is also a practical point here that often gets overlooked.
Most web development agencies have a lot of experience working with PHP based systems. Drupal, WordPress, Laravel, Symfony, all of these sit in roughly the same ecosystem. Once you move into the world of SaaS integrations and external applications, you're suddenly dealing with a completely different development model, and that often means a smaller pool of developers who are comfortable building and maintaining those systems.
Which is fine if your requirements are simple, but if you're trying to build something unusual it can quickly become awkward.
Now WordPress is a slightly different case because it's not a SaaS platform. You can install it yourself, run it wherever you want, and technically you have full control over the system. But in practice most ecommerce sites built with WordPress rely heavily on the plugin ecosystem around WooCommerce, and that ecosystem can be a bit of a mixed bag.
Some plugins are excellent. Really well built, well maintained, and written by people who clearly care about what they're doing. Others... less so.
One of the biggest issues I've run into with WordPress stores over the years is what I like to call plugin roulette. You install a plugin because it solves one specific problem, and then a few months later you discover that it conflicts with another plugin, or it hasn't been updated in two years, or the developer has decided that the free version is now extremely limited and you need to upgrade to the "Pro Ultra Mega Enterprise" plan to keep using the feature you already built your store around.
And because the WordPress ecosystem is so large, and because plugins can be installed so easily, it's very easy for a store to slowly accumulate a huge pile of third party code that nobody really understands.
I've opened up WordPress sites before where there are 40 or 50 plugins installed, some of them handling quite fundamental pieces of functionality, and at that point it starts to feel less like a coherent system and more like a tower made out of different bits of duct tape.
If you are a business that can get away with completely out of the box tools and store configuration then honestly you are extremely lucky. While that might be most small to medium sized businesses, I have never worked with a company that doesn't have at least one odd quirk that can't be fulfilled by just modules and plugins available off the shelf.
A question to developers out there, have you ever put together an ecommerce store that didn't need at least one custom module or plugin? And if you did, was it done with absolutely no concessions on the part of the client, or were there some compromises along the way. Because in my experience every business has some weird thing going on.
Maybe their pricing model is unusual. Maybe their ordering process involves multiple departments signing things off. Maybe certain products can only be bought by certain types of customers. Individually these things might not seem that strange, but they start to add up.
Out of curiosity the other day I went to have a look through the Shopify plugin store to see what it's like. Immediately I was met with something that anyone who has spent time in these ecosystems will recognise.
Free. Starter. Pro. Empire. Enterprise. Plus. Pricing tiers everywhere.
Now there is nothing inherently wrong with paid software. Developers deserve to be paid for their work and maintaining complex systems takes time and effort. But what made me slightly uncomfortable was how little visibility there was into what these plugins were actually doing.
I couldn't see the codebase. I couldn't see how the functionality had been implemented. In many cases I couldn't even see technical documentation.
So not only do I not really know what is being installed on my site, I also don't own it. What happens five years down the line when my store has grown significantly and suddenly the developers of that plugin decide to change their pricing model, or discontinue the product entirely?
I've seen this happen before. A plugin that a business relies on suddenly becomes expensive, or disappears entirely, and now you're stuck trying to replace a critical piece of functionality that your entire workflow depends on.
You see similar issues in the WordPress ecosystem as well, especially with premium plugins. I've worked on projects where a store depended on several paid WooCommerce extensions, each with their own licences, renewal cycles and update schedules, and managing all of that can become a job in itself.
Let's contrast that with Drupal Commerce, or indeed most modules in the Drupal ecosystem. They are open source.
As a developer I can go and look at the code. I can understand exactly what the module is doing. If something breaks I can fix it. If I need to extend it I can extend it. And perhaps most importantly, if the original maintainers ever stop supporting the module, the code doesn't just disappear. It's still there.
That kind of transparency and control is incredibly valuable when you're building systems that businesses depend on.
Being entirely honest, I've had a lot of fun changing some fairly fundamental assumptions inside Drupal Commerce. Many ecommerce platforms have a fairly fixed idea of what the world looks like.
What is a product? Who owns a basket? What does the checkout process look like?
For many businesses those assumptions line up nicely with how they already work, so everything feels simple and straightforward. But not everyone fits neatly into that model. Because Drupal Commerce sits inside Drupal, and because Drupal itself is built on flexible systems like entities, services and events, those assumptions are not set in stone.
Let's walk through an example that starts off simple and slowly gets a bit more interesting.
In a normal ecommerce store a basket belongs to a single customer account. That customer adds products to the basket, goes to checkout, pays for the order, done.
Now imagine a slightly different requirement. Instead of a basket belonging to a single customer, the basket belongs to a project. Multiple users can be members of that project. Some users can add items to the basket. Some users can approve purchases. Some users can view the project but not change anything. And the basket itself represents the combined purchasing activity of that entire project.
This might sound unusual at first, but it's actually something we built for a real client. The system is live, it is in production, and it is actively generating revenue.
Now imagine trying to build that on a platform that assumes that a basket always belongs to a single user account. You would very quickly find yourself fighting against the assumptions built into the system. With Drupal Commerce we didn't have to fight the system, we just adapted it.
Drupal Commerce provides a framework, and that framework is robust and well thought out, but because it sits within Drupal it isn't rigid. You can extend, adapt (and/or overcome 🐻) it. And when necessary you can replace parts of it entirely.
For complex requirements like the one above, Drupal Commerce might get you 70–80% of the way there out of the box, but it also gives you the tools to build the remaining 20–30% in a clean and maintainable way.
I never want to have to tell a client "no". There are always conversations about what the best solution is, and those conversations are important, but there is a key word in there... Best.
The best solution for a business is almost never something that exists perfectly off the shelf. Every business works slightly differently. Even businesses that look very similar on the surface often have completely different processes once you start looking under the hood. And in my opinion a system should be able to adapt to the way a business works, not force the business to adapt to the system.
That is where Drupal Commerce really shines. It provides structure, it provides sensible defaults, it provides a lot of functionality out of the box, but it also stays flexible enough that when a business has one of those weird requirements... and they always do... you don't have to say no. You just build it.
