WooCommerce and configurable products: where the limit is
Let's start with something few custom development companies will tell you: if your online store has a standard catalogue, WooCommerce is probably your best option. Products with their photo, price and stock; a limited set of variants such as size or color; the usual shipping and payment gateway. That's what it was built for, it does it extremely well, and there are very good agencies that specialize in setting it up properly. Building that store from scratch would be throwing money away, and if you ask us to, we'll tell you so.
This isn't a view from the outside, either: we run WooCommerce in-house too, because for what it does it's the right choice. This article isn't against the platform. It's against using it outside its territory, which is where projects get stuck. And its territory ends at a very specific point: the configurable product.
What a truly configurable product is
We don't mean a T-shirt in three sizes and four colors. Those are variants, and WooCommerce handles them out of the box. We mean what we saw in a real project: a manufacturer whose customers configure the product as they buy it. They choose the dimensions. They choose the firmness. They choose the fabric and the finishes. All within options the manufacturer defines, but combinable with each other, and every choice affects the final price and which other options are still available.
The difference from variants isn't one of size: it's one of nature. A variant is a product that already exists and is waiting in a warehouse. A configuration is the description of something that is going to be made. The store stops selling items from a list and starts validating the customer's decisions and pricing them. It's a different problem, and tools designed for the first one feel it.
Where it starts to break
Variants grow combinatorially. WooCommerce turns every combination into a variant: a child product with its own price and stock. With two short attributes, that works. In the manufacturer's project there were four attributes with up to twenty values each: the possible combinations shoot up to numbers that make no sense to create one by one, and even trimming down to the ones with real demand, the catalogue was around a hundred variants per product. Maintaining that by hand (prices, images, availability) turns every price change into an afternoon of work.
Price modifiers aren't native. In a configurable product, the price isn't "this variant costs this much": it's a base price plus whatever each choice adds. This fabric adds one amount; this finish, another; the dimensions change the base. The WooCommerce model puts the price on the final variant, not on the option chosen. So either you calculate it elsewhere and maintain the price of every combination by hand, or you install an extension that calculates it for you.
Neither are compatibility rules. The same project had around twenty rules of the "this firmness doesn't exist in that size" kind. The variant model can't express them: out of the box, the impossible combination can be bought anyway, and the error doesn't show up on the website but later, when the order reaches production.
And it all ends in a pile of extensions. There's a plugin for each of these gaps. From different authors, with different data models, each one solving its part without knowing the others exist. You install three or four, they start stepping on each other, and every update to the platform or to any of them can upset the balance: what calculated a price correctly yesterday gets it wrong today, and someone has to work out which piece caused it. The store works, but it lives under permanent review.
Cheap gets paid for in maintenance
The pattern is familiar: getting started costs little (the platform is free and the extensions come ready-made) and the real cost shows up later, in hours spent keeping the balance between pieces that don't know each other. It's the same logic we describe in cheap build, expensive maintenance, with one difference: there, expensive maintenance is a vendor's business model; here, nobody is to blame, it's technical debt that piles up on its own. The result for the business is the same: every month it costs more to have the same thing.
What to do if you're at that point
The decision comes from one honest question: is the configurator an extra in your store, or is it your business?
If it's an extra, the sensible way out may be to simplify: fewer attributes, closed options, a catalogue that fits the variant model. It's a legitimate business decision, plenty of companies make it, and you don't need custom development to carry it out: any good WooCommerce agency can handle it for you.
If the configurator is the business (if what sets you apart is precisely that customers choose dimensions, materials and finishes others don't offer), then that piece deserves to be your own software: a custom configurator where rules and prices are modeled as what they are, not simulated with variants. And it's worth looking at what comes after, because a configured order has to reach production without anyone typing it in again. That's where the configurator often ends up being the first module of something closer to a custom ERP than to a store.
How we work is public: an hourly rate and a monthly dedication you decide, on our rates page. And if you're not sure which side of the line your catalogue falls on, tell us what it looks like and we'll give you a straight answer. Including the answer that you should stay on WooCommerce, if that's where your store belongs.