The Plugin Audit
Every new WooCommerce client at WPify starts the same way. Before we touch anything, we open the plugins screen and count.
The number is rarely below forty. And when you group the plugins by what they actually do, the same cluster shows up nearly every time:
- a plugin for "Buy 2, get 10% off"
- a different plugin for free gifts above a cart threshold
- an upsell plugin for the cart
- a "frequently bought together" plugin someone installed during a Black Friday panic
- a countdown timer plugin
- a plugin that hides cash on delivery for some orders
- a gift voucher plugin that half works, so somebody on the team creates coupons by hand every December
Seven plugins. Seven authors. Seven settings screens. Seven sets of hooks into the same cart totals, all running on every page load, and all assuming they’re the only ones changing the price.
The store owner never chose this architecture. It grew one marketing idea at a time. Each campaign needed one feature, the quickest fix was another plugin, and nobody ever went back to clean up.
What This Actually Costs
The obvious cost is money: seven licences renewing on seven dates. That’s the smallest problem.
Conflicts. Two plugins that both modify cart totals don’t know about each other. One applies a bulk discount, the other applies a coupon. The order in which they run depends on hook priorities that neither author coordinated. In practice that means a customer gets two discounts stacked when you meant them to be exclusive, or a free gift that vanishes when a coupon is applied. These bugs only show up with specific cart contents, which is exactly why they reach production.
Performance. Each plugin loads its own scripts and styles. Many recalculate the cart on every AJAX request. The checkout, which is the one page where speed matters most, ends up carrying the most code.
Updates. When WooCommerce changes something in the cart or checkout (and the switch to block-based checkout changed a lot), every one of those plugins has to adapt. Some do it quickly. Some never do. You find out which ones after the update.
People. The marketing person who wants to run a weekend promotion has to remember which of the seven screens controls which rule. So they don’t. They ask a developer, and a promotion that should take ten minutes turns into a ticket.
We fixed this pile by hand for client after client, removing plugins, writing small custom pieces and wiring them together. After enough repetitions, the question became obvious: why are we rebuilding the same thing in every project?
One Plugin, Modules You Can Switch Off
Sales Booster Kit is our answer. It’s a single WooCommerce plugin with independent modules:
- Discount rules: product and cart discounts, bulk pricing, bundles, Buy X Get X, Buy X Get Y, free gifts and in-cart upsells, each with start and end dates.
- Cross-sells and upsells: recommendations on the product page and in the cart, with one-click add-to-cart and targeting by cart value or contents.
- Frequently bought together: pairings generated from real order history, with manual overrides where merchandising matters.
- Countdowns, progress bar and delivery dates: "You’re €12 away from free shipping", flash-sale timers, "order today, delivered by Thursday".
- Shipping and payment conditions: show, hide, rename or re-price methods, and add fees, by cart, products, customer, country or currency.
- Advanced coupons: the eligible coupon shown on the product page, optionally auto-applied, including on variable products.
- Product vouchers: sell a gift voucher, generate a PDF in your fonts and colours, and email it automatically.
Phone-number validation comes along too: the number is checked and normalised before the order is submitted.
The important word is modules. Each one is switched on separately. A store that only needs checkout rules turns on checkout rules, and the other modules stay out of the way. You don’t pay in performance for features you don’t use.
Every plan includes every module, including future ones. Plans differ only in the number of sites and the level of support. We didn’t want a store owner to discover mid-campaign that the feature they need sits behind a higher tier.
How It Avoids the Stacking Bug
The second important thing is that the discount types share one engine for touching the cart. Bulk discounts, BOGO offers, free gifts and cart discounts don’t race each other for the last word on the total, because they’re the same code with one clear order of operations.
That order has a name in the documentation: the cart pool.
- When the cart is calculated, every item starts in the pool, undiscounted.
- Rules run in priority order. A lower number runs first.
- When a rule applies, the items it used leave the pool. For a "Buy 3, get 1" rule that’s all four, the three that triggered it and the one it discounted.
- The next rule only sees what’s left.
So with ten units in the cart, "Buy 3, get 1" at priority 0 takes four, and "Buy 2, get 1" at priority 10 works with the remaining six. The same unit is never discounted twice. When two offers compete for the same units, priority decides which one the customer gets, so you give your best offer the lowest number. That’s a decision you make once in the rule list, not a hook-priority race you discover in production.
How a discount shows is a separate choice, called the application mode:
- as a lower product price, with the old one crossed out, for product, bulk and bundle discounts
- as its own line in the cart, named after the rule, so product prices stay untouched
- as an item: a "choose your gift" picker in the cart, an offer on the product page, a product added to the cart automatically, or, on the classic cart page, a checkbox under the cart item ("add the socks for half price")
The free-shipping progress bar, the discount countdown and the product badge are part of the same discount rules, so they read the thresholds and dates from the rule itself instead of from a second set of settings.
Rules for Shipping and Payment
The module that saves the most support tickets in our projects isn’t a discount at all. It’s the one that decides which shipping and payment methods a customer sees.
A rule can show, hide or rename a method, change its price by a fixed amount or a percentage, add a fee, or switch a payment gateway on or off. The conditions cover cart value, products and categories, applied coupons, customer role, country, shipping zone, currency and product type, and they combine, with priorities, for the cases that need more than one.
The examples in the documentation read like our clients’ requests:
- free shipping from a €75 subtotal
- no cash on delivery above a set order value
- a fee on cash on delivery, while online payments stay free
- a surcharge for bulky or fragile products
- bank transfer for domestic orders, card only for orders abroad
- no pickup-only methods when cash on delivery is selected
Things We Were Strict About
WooCommerce-native. No custom checkout, no parallel cart. We use WooCommerce’s own data structures and hooks, because the moment you invent your own cart, every other plugin in the ecosystem stops understanding you. It’s the same reason it works with the page builders stores actually use: Gutenberg, Elementor, Bricks, Divi, Beaver Builder and Oxygen.
A store owner can run it alone. Every rule is built in a point-and-click interface: conditions, targeting, start and end dates. There’s no setup wizard to get through. The goal is that the person who has the idea for a campaign can launch it without a developer.
Margin-friendly by default. A store-wide 20% sale is the easiest promotion to build and the most expensive to run. It teaches customers to wait for the next one. Most of the modules are built around the opposite idea: reward a bigger cart, a specific bundle or a second item, and protect your margin on everything else.
Built for European stores. We’re based in Prague, and most of our clients sell across several EU countries. Rules by country and currency, hiding cash on delivery for high-value orders, delivery-date messaging: these aren’t edge cases for us. They’re Tuesday.
Developers aren’t locked out. The rule calculation, the admin interface and the integrations have documented hooks, and the front-end output goes through a template system. When a client needs something the interface doesn’t cover, we extend the plugin instead of working around it.
What Stores See
I’ll let the product site speak for the numbers, since they come from stores using it, not from me. Testimonials on the Sales Booster Kit site report figures such as a 31% lift in average order value from targeted discount rules, and an accessories attach rate going from 8% to 27% with cart upsells (salesboosterkit.com). Your results will depend on your products and your customers. What I can say from our own agency work is simpler: when we replace the plugin pile with one coherent system, promotions stop breaking checkout, and the marketing team stops filing tickets.
When It’s Not the Right Tool
To be fair:
- If you need one feature and you already have a well-maintained plugin that does it, keep it. Consolidating for its own sake isn’t the point.
- If your promotions need logic that is truly custom, like pricing from an ERP or contract prices per B2B customer, you’ll likely still need custom code. That’s what the agency side of WPify is for.
- If you’re not on WooCommerce, this obviously isn’t for you.
Try It
You need WordPress 6.2 or newer, WooCommerce 8.0 or newer and PHP 8.1 or newer. Installation is a ZIP upload. The essentials take about a quarter of an hour, and we help with the installation and first setup if you want us to.
There’s a 14-day free trial with full access to every module, and a 14-day money-back guarantee after you buy. Install it on a staging copy, switch on one module, and rebuild your current biggest promotion with it. That’s the quickest way to find out whether it can replace the pile.
→ salesboosterkit.com · pricing · documentation
And if you’re a developer who has inherited a store with forty plugins, I’d like to hear what’s in your pile. Write me at [email protected].
