A business spends hundreds of thousands of dollars with a developer or agency to build an eCommerce website, endures years of instability and missed deadlines, and then concludes that the platform just doesn’t work. They start eyeing Shopify or whatever choice platform the first consultant they engage recommends, hoping the grass will be greener. Meanwhile, the actual issue—an underqualified or negligent service provider—walks away unexamined.

Developer problems are often disguised as platform problems. We’ve seen this situation many times with Drupal Commerce implementations that aren’t performing as desired. We’ve even solved issues merchants put up with for years in a matter of hours. It’s not that we’re special, though we do know our own platform better than anyone else. We believe any competent Drupal developer would also be able to identify and solve these issues, possibly just as quickly.

So how do you tell the difference? How do you know your issues stem from your developer, and not your platform?

Below, we’ll give you the language and the lens to evaluate whether your developer is actually serving you well, or whether they’re the reason your Drupal Commerce site feels like it's held together with duct tape and bubblegum.

How some developers get in over their heads

A company needs a Drupal website with eCommerce capabilities, so they search for a Drupal developer. Maybe they already have a Drupal website and want to add some commerce features. Either way, they find a freelancer who has built blogs, nonprofit sites, and maybe a university portal with some advanced functionality. That person says, "Sure, I can handle commerce. It’s just another module." For a basic eCommerce website with minimal traffic, maybe they can.

But Drupal Commerce is a highly customizable commerce framework built on a sophisticated open-source architecture. Managing it well at scale requires deeper knowledge of the platform, its ecosystem, and development best practices. When someone without that depth takes the reins, they accumulate technical debt almost immediately that will compound over time.

Every future improvement becomes harder and more expensive. Any bump in traffic can choke the website. New product launches become a chore where you cross your fingers and hope for the best. A backlog of security updates remain undeployed.

For a website with 5 products doing 25 orders a month, this technical debt might not seem like a big deal. But for a business whose website is mission-critical, with thousands of products, thousands of orders, systems integrations, and finely-tuned fulfillment processes, technical debt can bring the whole organization to its knees.

All because one developer didn’t know what they didn’t know.

Red flags you should be watching for

After inheriting, rescuing, and rebuilding dozens of Drupal Commerce sites, certain patterns show up over and over. If any of these sound familiar, it's time to ask hard questions.

The code is not managed in Git

Your entire codebase (custom modules, configuration, patches, everything) should live in a Git repository, and in a Git repository 100% under your control. Not a zip file on someone's desktop. Not a folder on the web server with date-stamped backup copies. A proper, version-controlled repository with a clear history of every change, who made it, and when.

We've worked with developers whose idea of version control was copying the entire web root into a backup folder labeled with a date. They subscribed to the “hope and pray” method of rollback strategies.

Without Git, you have no way to see what changed between last Tuesday and today. No way to isolate a breaking change. No way for a second developer, or a replacement, to come in and understand the project's history. You also lose the ability to use pull requests, code review, automated testing, and every other modern practice that depends on version control as its foundation.

When we onboard a client in this situation, one of the first things we do is walk them through setting up a GitHub organization and repository. It takes a single afternoon.

No local development

This is the most basic one, and it's shockingly common. Your developer should be writing and testing code in a local development environment before it ever touches your live site. Tools like DDEV make this straightforward.

If your developer is editing code directly on your production web server or editing configuration through the admin UI on a live site, they are introducing instability with every change. Editing on production hasn't been an acceptable practice for 15 years, and still we routinely encounter it.

No proper staging or QA environment

Before any change goes to production, it should be tested on a staging environment that mirrors production as closely as possible. This isn't an exotic requirement, nor is it hard to obtain! It’s table stakes for every major Drupal hosting platform. Pantheon, Upsun, and Acquia have provided development, staging, and production environments, with synchronization tools, for well over a decade. 

However, half our clients' developers don't use them. We hear the same things over and over: "Our staging environment hasn't been synced in forever." "We had a test environment, but it's been down." “We just demo new features via screen share on their own machine.”

This is a solved problem. If your developer can't maintain a functional QA environment, that alone tells you something important.

Security fixes can’t be deployed

When a security vulnerability is disclosed for Drupal or any of its contributed modules, you should be able to patch your production site the same day. Not next week, and certainly not next month. The same day.

If your developer tells you that deployments require extensive coordination, that pushing even a small fix is blocked by some unrelated issue, or that they need days to prepare, they have let their technical debt put your business at risk. Your site is exposed for far longer than it should be. Every modern Drupal hosting platform supports rapid deployments, and any seasoned developer should be able to take advantage of that.

Your website is years behind on platform updates

Go to the Drupal Commerce project page and check the current version number. If your site's version starts with a "2," you are years out of date. You're missing performance improvements, bug fixes, security patches, and major new features — including a completely overhauled order management system.
When we ask developers why they haven't updated, the answer is usually some version of "we have custom code that would break." 

But Drupal Commerce maintains the same backward-compatibility standards as Drupal core. Deprecated APIs are preserved across versions. Migration paths are provided. If your developer wrote code so tightly coupled to the old internals that a standard update breaks it, that's a reflection of their code quality, not the platform's stability.

We keep our clients current with as little as six hours of maintenance per month. One working day per month is all that’s needed to have the latest and greatest. If your developer can't keep you updated with that level of effort, what are they spending their time on?

Contributed modules are hacked

Drupal's ecosystem includes thousands of contributed modules maintained by the community. When a module doesn't do exactly what you need, the proper approach is to either extend it using Drupal's object-oriented architecture or maintain a patch file tracked in your codebase through Composer.

Instead, we see developers editing contributed module files directly. Even worse, we’ve inherited sites where the previous developers copied an entire contributed module into the custom modules directory and modified the copy. This means the site has two versions of the same module in its codebase, and only by accident is Drupal loading the right one. You can't update the original without losing the changes. You can't even tell what was modified without a line-by-line comparison.

These hacks make a site unmaintainable by anyone other than the person who made the mess, which is its own form of vendor lock-in, and often, not even the person who made the changes remembers what they did.

Configuration is not kept in code

Drupal 8 introduced configuration management to core over a decade ago. It allows every configuration change (e.g., content types, fields, Views, and permissions) to be exported to code, versioned, reviewed, and deployed predictably across environments.

If your developer is still making configuration changes directly against the production database (which means they are adding fields, content types, Views, and more through the UI on the live website), they are operating with tools and practices from a bygone era. There is no staging of changes, no review process, no ability to roll back cleanly. It's the digital equivalent of performing surgery without running any tests or imaging.

Configuration files should be exported and kept in a Git repository.

You don't own your own infrastructure

Every piece of your digital commerce platform should be under your control. Your hosting account should be in your name or easily transferable to you. Your source code should be in a repository you own. Cloud storage, domain registration, all of it.

When we onboard a new client, we make sure they have the keys to their kingdom. We only get added as collaborators. If they ever need to fire us, they can remove our access and hire someone else the next day. That's one of the promises of open source, when implemented with best practices.

Too many merchants have their codebase in their developer's personal repository, their site on the developer's hosting account, and their files in the developer's AWS bucket. If that developer disappears — retires, gets hit by a bus, or simply stops returning calls — the merchant is stranded. We've seen it happen.

“Headless” is seen as a solution to all of your performance problems

When a Drupal Commerce site has performance problems, an inexperienced developer's first instinct is often to go fully headless. They’ve heard that it’s easy to build a faster front-end in Next.js and reduce Drupal to an API server. In theory, it sounds great!

In practice, it doubles your complexity. You now need expertise in both Drupal and a front-end framework. You need to monitor GraphQL or REST API performance. Every new feature requires work on both sides. And you've introduced a build pipeline and deployment process that can block updates and security patches.

Some performance problems can be solved by adjusting a single database setting, but it takes knowledge and experience to know which one. Sometimes it’s a simple refactor of custom functionality or a decoupling of one specific feature to streamline costly back-end processes. Maybe tweaks to the hosting environment. Going headless in these instances is a huge waste of time and budget. 

Going fully headless isn't always wrong. We've scaled sites to thousands of concurrent shoppers by progressively decoupling specific components with JavaScript, without abandoning the full-stack architecture. We also maintain fully decoupled sites that process tens of millions of dollars per year in transactions. 

But decoupling should never be the first move when you're struggling with performance. Optimize what you have first.

The cost of loyalty

We understand the sense of obligation toward a developer or agency that got you where you are. They built what you have and enabled the success you currently experience. Maybe you’ve worked with them for years.

But loyalty has a cost when it prevents you from seeing the situation clearly. The horse you rode in on might not be the horse that can take you to the next stop. The person who got you to this point may deserve credit for much of your current success, but if they can't get you to where you need to go next, you’re going to be stuck forever.

We've watched merchants spend six figures on freelancers only to have our team rewrite entire features from scratch in a fraction of the time. We've seen developers bill for months of custom development to build features that already existed as a contributed module. These instances represent real costs and lost opportunities.

It’s okay to admit that you have outgrown your current developer.

What you should expect from a qualified Drupal Commerce partner

Here are the baseline expectations:

• Local development environments for every developer on the project
• A proper staging environment that mirrors production and stays synchronized
• Version-controlled code in a repository you own
• Composer-based dependency management with tracked patches
• Configuration management through code, not database edits
• Regular platform updates requiring minimal monthly effort
• Same-day security patching capability
• Clear separation between contributed and custom code

If your current developer or agency can’t check each of these boxes, the frustrations you’re experiencing probably have nothing to do with the platform. You’ve been unknowingly stymied by an unqualified practitioner.

If you give this list to your developer and they start making excuses, even if they sound reasonable to you, it’s time to move on.

You don't have to put up with this

Drupal Commerce is an enterprise-grade platform that powers complex, high-volume commerce operations around the world. When it's implemented and maintained properly, it's easy to customize, performant, and built to last.

If your experience doesn't match that description, don't blame the platform. At least not before you've evaluated the people managing it. The problems we see most have solutions that have been around for years. These solutions aren’t mysteries. They’re not cutting-edge or difficult to implement. They’re just best practices your current provider never adopted.

If you want to prepare for the future and focus on growing your business, it’s time to stop throwing away good money to get middling results.