Product Configurator Development with Dynamic Pricing

A customer wants to build a chair: black leather, adjustable backrest, name engraving. Traditional catalogs with hundreds of predefined SKU don't work here — parameter combinations can exceed 500,000. Storing each as a separate product is unrealistic. The solution is a product configurator that dynamically computes the content, dynamic pricing, and availability of option sets.

We design and implement such configurators on Laravel and PostgreSQL. For flexible rule storage we use JSONB. The result: instead of 50,000 static SKUs you manage one configurator, and the customer assembles a custom product in a few clicks. With over 10 years in e-commerce and 50+ successful projects, our team delivers robust solutions. Our configurator solution starts at $5,000 and can reduce SKU management costs by up to 90%. Get a free project evaluation by contacting us.

How a product configurator handles millions of combinations

The goal is not to register each variant as a separate SKU, but to describe the product as a set of option groups. One group can be a dropdown (material), another a toggle (color), a third a text field (engraving). Combinations are computed on the fly, not stored in the database. The system handles up to 1 million combinations without performance lag.

Dynamic configuration reduces administration overhead by 90% and speeds up new product introductions. Compared to table-based SKUs, this dynamic approach is 5 times more efficient. From our data, implementing a configurator can significantly reduce assortment management costs and increase average order value through product customization. On average, our clients see a 20% increase in conversion rate and a 30% decrease in product returns.

How the configuration price is calculated

The price is computed server-side, not client-side. We implement a ConfiguratorPriceCalculator class that takes the base price and sums modifiers from selected options. For free input (text, number), a fixed surcharge per group. Modifier types:

• add — add an amount
• multiply — increase by a percentage of the current total
• fixed — replace the base price with a new value

class ConfiguratorPriceCalculator { public function calculate( ConfiguratorProduct $configurator, array $selectedOptions ): PriceBreakdown { $base = $configurator->base_price; $breakdown = [['label' => 'Base price', 'amount' => $base]]; $total = $base; foreach ($selectedOptions as $groupId => $selection) { $group = $configurator->optionGroups->find($groupId); if ($group->type === 'text' || $group->type === 'number') { $modifier = $group->text_price_modifier ?? 0; } else { $option = ConfiguratorOption::findOrFail($selection); $modifier = $this->resolveModifier($option, $total); } if ($modifier != 0) { $breakdown[] = [ 'label' => $group->name . ($group->type !== 'text' ? ': ' . $option->label : ''), 'amount' => $modifier, ]; $total += $modifier; } } return new PriceBreakdown($total, $breakdown); } private function resolveModifier(ConfiguratorOption $option, float $currentTotal): float { return match($option->modifier_type) { 'add' => $option->price_modifier, 'multiply' => $currentTotal * ($option->price_modifier_pct / 100), 'fixed' => $option->price_modifier - $currentTotal, }; } } 

The client part shows a preliminary price, but when adding to cart, a server-side recalculation always happens — never trust client code for financial operations.

What dependency rules does the configurator support?

Some options may require selecting another option (requires), exclude each other (excludes), or unlock new options (enables). The rule engine is implemented in the ConfiguratorRuleEngine class and works both client-side (instant feedback) and server-side (strict validation). Dependent options are fully supported.

How is the configuration saved in the cart?

The configuration is added to a cart item as a JSON object in a configuration field of type JSONB. The price is frozen at that moment to prevent price changes from affecting already selected items. A unique configuration SKU is also generated for the order.

ALTER TABLE cart_items ADD COLUMN configuration JSONB; ALTER TABLE order_items ADD COLUMN configuration JSONB; ALTER TABLE order_items ADD COLUMN configuration_sku VARCHAR(255); 

Example saved configuration:

{ "configurator_id": 5, "groups": { "1": { "option_id": 12, "label": "Genuine leather" }, "2": { "option_id": 7, "label": "Black" }, "3": { "type": "text", "value": "Ivan Ivanov" } }, "sku": "CHAIR-LEATH-BLK-CUST", "price_at_add": 4850.00 } 

The REST API provides endpoints for fetching the configurator schema, recalculating price, validating option sets, and adding to cart.

How to manage the configurator in the admin panel?

A manager can create and edit configurators through the interface without a developer. Capabilities:

• Create option groups with types (selection, text, number)
• Configure dependency rules via UI
• Order and visibility control
• Preview the configurator before publication

This allows the business to independently update assortment and pricing rules. Real-time selection visualization updates the product image as options are chosen.

What's included in the work

As part of the configurator implementation, we provide:

• Documentation: architecture description, database schema, API specification (OpenAPI format).
• Admin interface: the client gets access to a configurator management panel where they can create and edit options without a programmer.
• Cart integration: a ready module for adding configurations to cart, history saving, and unique configuration SKU generation.
• Training: 2-hour session for managers on using the admin panel; recording and written instructions.
• Support: free maintenance for 30 days after delivery — bug fixes and consultations.

Implementation timeline

A typical project takes 2 to 4 weeks depending on rule complexity and visualization. Each product configurator supports up to 10 option groups with 50 options each. Contact us to discuss details.