3 WooCommerce limits that push growing stores toward a custom build

If you're running a store on WooCommerce and something keeps not quite working, there's a good chance the problem isn't you or your team. Over 760 builds in 15 years, I've watched the same three structural limits push growing stores to a point where the workaround IS the system. WooCommerce is the right tool for a certain kind of store. This post is about what changes when you're no longer that kind of store.

WooCommerce is fine, until these three things break it

WooCommerce is a genuinely good platform for a straightforward store. A few hundred SKUs, standard checkout, standard shipping rules, a single warehouse. I've recommended it to dozens of clients and I'd recommend it again for that use case without hesitation.

The problem is the word "straightforward." When your business grows past it, WooCommerce doesn't grow with you. It accommodates. There's a real difference. What follows are the three places I've seen it break down. In each case, the clients tried to fix a structural limit with plugins first. In most cases, that made things worse.

Limit 1: Checkout logic you can't write in plugin settings

WooCommerce's checkout assumes one thing: a customer picks a product, fills in their details, pays, and leaves. The moment your pricing or checkout flow depends on anything more conditional, you're fighting the model.

Conditional pricing is where it usually starts. Tier-based discounts based on order history, role-specific pricing for trade accounts, bundles that price differently depending on what else is in the cart. There are plugins for all of these. The trouble is that each one defines its own price calculation hook, and when two or three plugins all fire on woocommerce_get_price, they don't agree on the order. You end up debugging race conditions in a system you didn't write and can't easily change.

Multi-step checkout compounds it. Say you need to collect a measurement, confirm a delivery slot, or run a credit check before the payment screen. WooCommerce's checkout is one form with one flow. Plugins that bolt on extra steps work until something changes: a new payment gateway, a WooCommerce major release, a PHP version bump. Then they stop working.

Plugin settings are configuration. They let you toggle behaviour that was already built. They can't change what the checkout fundamentally is. If your actual checkout logic doesn't fit the model, adding plugins multiplies the problem because each new one adds its own dependencies, its own update cycle, and its own way of hooking into the same core functions.

Custom code lets you define checkout logic that fits your actual rules, written once, tested to your spec, not dependent on a third-party developer keeping their plugin current.

Limit 2: Catalog filtering that doesn't match your actual catalog

WooCommerce organises products in a specific way: products, categories, tags, and variations. For a lot of stores, that's enough. For stores with deep technical attributes, configurable products, or cross-sells that don't fit the hierarchy, it's a cage.

The attribute model is flat by design. Every attribute is a key-value pair attached to a product. If you need hierarchical attributes (think: fabric type, then fibre content, then thread count), or attributes that appear conditionally based on other attributes, the default model can't hold them. You can work around it with custom taxonomies and creative filtering logic, but the further you push it, the more fragile it becomes.

Catalog filtering breaks at roughly the same point. WooCommerce's layered navigation filters on the attributes and categories the model supports. If your customers need to filter by something the model doesn't know about, you add another plugin. Each additional plugin runs its own database query. In stores I've worked on with 5,000 products and six active filter plugins, a single filtered page load commonly triggers 40 or 50 database queries.

The rule I've seen hold across every rebuild: the catalog model should match how your customers think about your products, not how WooCommerce's taxonomy works. When you're routing customers through a workaround, you're losing sales that are hard to count.

A custom build lets you design the data model first, then build the filtering on top of it. The queries target your actual filter combinations. The results are fast because the system knows the shape of your catalog.

Limit 3: Fulfillment rules the platform was never designed to hold

This is usually where I get called in. Checkout and catalog problems are visible to customers. Fulfillment problems are invisible right until something ships to the wrong address, from the wrong warehouse, via the wrong carrier, at the wrong rate.

WooCommerce's shipping model covers zones and shipping classes adequately for a store shipping one product type from one location with a few carrier options. It breaks immediately when you add multiple warehouses, routing rules that send certain products to certain locations, carrier selection logic based on dimensions or weight combinations, or any integration with a third-party fulfillment system.

The typical fix is fulfillment plugins, sometimes three or four of them, each handling one piece of the logic. Together they create a dependency graph that nobody fully understands.

The real rules live elsewhere. They're in a spreadsheet someone built in 2019. They're in a Slack thread where a logistics manager described an exception. They're in an email chain nobody can find. WooCommerce has no place for this logic, so it never moves into the system. It lives in human memory, which means it breaks every time a person leaves.

The cost compounds every quarter you stay

Here's what I see in stores that have been fighting this for two or three years. They're running 12 to 18 active plugins touching checkout or fulfillment. Every WooCommerce minor release is a risk event: test, find two or three incompatibilities, pay a developer 3 to 6 hours to sort it out. Four times a year, that's 12 to 24 developer hours just to stay still.

Plugin authors drift. Abandoned plugins are common. A plugin actively maintained in 2021 might not have had a commit in 18 months. You're running it anyway because replacing it means rebuilding the logic it contains, and nobody documented what that logic actually is.

The gap between what your system does and what your business actually needs widens every quarter. You add workarounds for workarounds. The team spends real hours each week on tasks that should be automatic.

Is your checkout logic spread across plugin settings screens that conflict with each other, your fulfillment routing in a spreadsheet someone updates manually, and your team absorbing four hours a week catching what the system gets wrong before dispatch? Custom feature development moves those rules directly into the system: a checkout flow that matches your actual order types, catalog filtering built around how your buyers think about your products, and fulfillment routing that runs automatically on every order rather than relying on a person to be the safety net. When the rules live in the system, four hours of weekly exception-catching drops to thirty minutes, and wrong-warehouse pulls stop. Build the store around how you actually sell →

Before and after: one fulfillment workflow, rebuilt to fit

A client came to me running a mid-size WooCommerce store with two warehouses and roughly 3,200 active SKUs. They had four fulfillment plugins installed. Their order routing logic (which warehouse fulfills which order, based on stock, customer location, and product type) existed in two places: a plugin's settings screen and a spreadsheet a logistics coordinator updated manually each time the rules changed.

Before the rebuild, the coordinator was spending about four hours a week checking orders against the spreadsheet and correcting routing errors before dispatch. Wrong-warehouse pulls happened two or three times a week. Each one cost roughly 40 minutes to catch and fix.

We moved the routing logic into code. Not into another plugin. Into a purpose-built routing module that reads from a rules table the client owns and can update through a simple admin screen. The logic is exactly what was in the spreadsheet. It just lives in the system now, runs automatically on every order, and has a test suite.

After the rebuild: the coordinator's four hours per week dropped to 30 minutes of exception review. Wrong-warehouse pulls in the first three months after launch: zero. The rules table has been updated seven times since go-live. Each update took under five minutes.

That's one build, not a promise. But the pattern holds: when the rules move from workaround to system, the system stops requiring a person to be the safety net.

How to know you're ready for a custom build

You're probably past the WooCommerce limit if any of these are true:

• Your team has someone whose job partly involves catching what the system gets wrong.
• You've had a developer say "we can't do that in WooCommerce" and then spent money on a plugin that sort of does it.
• Your checkout or fulfillment rules exist somewhere other than the system (a spreadsheet, a Slack thread, a document nobody updates).
• A WooCommerce release or plugin update caused a production incident in the last 12 months.
• You're running more than eight plugins that touch pricing, checkout, or shipping.

You don't have to throw WooCommerce away to fix this. Sometimes the right answer is a hybrid: keep the storefront, replace one specific layer with custom code. Sometimes a full rebuild makes more sense. The way to find out is to describe the constraint specifically.

What's the rule your system can't hold? That's the right starting question.

If the rules that run your store live in a spreadsheet or a Slack thread instead of the system, custom development is the most direct path to moving them in. See how a custom store is built around your rules →