Building a WooCommerce product configurator with real products as options

A configurator feels like one product choice to a customer, but a store needs to identify every paid component. That difference determines whether stock, tax, discounts, refunds, and fulfilment remain understandable. Yindle Kit Configurator therefore uses real WooCommerce products as options. Each paid option enters the cart as its own line with its own SKU, price, stock, and tax class.

Design the product model first

Decide which choices are required, which quantities can vary, and which combinations make sense. Create a WooCommerce product with a stable SKUfor every saleable component. Hidden surcharges may look simple at first, but they make the order harder to understand. Real products let warehouse staff identify the line and let WooCommerce apply its existing price, tax, stock, and discount logic.

Use steps customers can follow

Combine buttons, selects, images, quantities, and conditional logic. Show a step only when an earlier choice makes it relevant. A product-page estimate helps customers compare, but the cart remains authoritative for the final amount. The price request is bounded and read-only; it does not replace the cart or write a session. Test a coupon, a tax location, several quantities, and an empty or unavailable option.

Preserve the customer’s choices

A configuration should not live only as loose text on the order. The plugin stores a configuration ID, definition revision, labels, SKUs, and quantities in the order snapshot. Support can then see which version of the choice was ordered. Historical kits from version 1.0.14 without stable configuration data must be set up again. Make that a checkpoint before connecting existing products to a new configurator.

Review imports and sharing

For SKU migration, a preview lets you check local mappings before applying them. Apply a one-time bounded change, and preview again when a global group or source set has changed. If you need to send a selected Kit to a customer or colleague, Yindle Share Cart can let them review, merge, or replace the cart. That flow still depends on current prices and availability.

Include operations in the design

Record who may change components and how new versions are reviewed. A name or image is sales information, while SKU, price, and stock are operational data. Agree how you will test a disabled option, a changed tax class, and a new definition revision. Release a change only after checking a complete configuration, an existing shared link, and the order view again.

If you also use shared selections and a guided checkout, test the combined customer journey as one scenario. Check that the selected components remain identifiable when sharing, importing and ordering.

Test the complete order

Use staging with the active theme and the extensions you rely on. Check one configurator, two configurators on one page, different quantities, an unavailable component, tax, discount, order, cancellation, and refund. Review mobile controls and the final order lines. The Kit Configurator product page explains the product boundaries. For a calmer final order step, combine it with Yindle Checkout ; the Commerce Bundle includes these three components but not Terminal Payments.

Previous insight
Next insight

Start with your question

Where does your team get stuck?

Your first enquiry does not need to be a technical brief. Tell us which systems you use and where work gets stuck. Together we discuss what is possible and which step you can take next.

Discuss my project