How do you build a manufacturing CPQ system that is not just Excel in disguise?

CPQ means Configure, Price, Quote: configure the product, calculate the price and generate the offer. In simple ecommerce, a "color + size" variant is enough. In B2B manufacturing, configuration can mean hundreds of dependencies: motor, material, certification, dimensions, target market, voltage, delivery date, contract discount, component availability, allowed accessories and warranty terms.

That is why a good CPQ system does not start with a shiny 3D model. It starts with a question: which system owns the rules? If rules sit in spreadsheets, engineers heads and production emails, the configurator only helps create bad quotes faster. If rules become a product domain, CPQ can shorten the sales cycle without increasing production risk.

At GMI Software we treat CPQ as B2B commerce plus domain backend plus integrations. MedusaJS can handle commerce core, price lists, cart and sales channels. NestJS can own rules, validation, approvals, documents and ERP/PIM/CAD integrations. Next.js gives customers or sales teams a fast portal, while BabylonJS/WebGL makes sense when 3D helps the buyer decide, not when it is only decoration.

In many companies the first CPQ version is a rewritten spreadsheet: fields, dropdowns, a few conditions and a PDF at the end. For the first weeks it looks successful. Then exceptions arrive: a strategic customer has a different margin, the German market needs another certificate, frame A does not fit motor B, a component is available only in plant X, and finance must approve discounts above a threshold.

If the system has no clear domain model, each rule becomes another frontend if-statement or another spreadsheet column. After a year nobody knows why a configuration was blocked, who approved the exception and whether the quote PDF still matches what ERP can manufacture and invoice.

The winning model is different: product catalogue, compatibility rules, pricing, BOM, approval workflow, quote documents and integrations are separate concerns. The frontend guides the user through the decision. The backend must be able to explain "why not" and "what needs to change for this configuration to work".

The first technical decision is whether the product can be described as simple variants or needs a constraint engine. Variants are enough when combinations are limited and stable. Constraints are needed when one component affects ten later choices and rules come from product physics, certification, manufacturing or warranty.

Salesforce describes modern CPQ configurators as supporting rules-based and constraint-based configuration. That distinction matters. "If the customer is gold partner, apply discount" is pricing. "A 20 kW motor cannot use the aluminium frame" is product compatibility. "Discount above 12% needs finance approval" is workflow. Mixing them in one place creates chaos.

During DDT we start with a decision tree and conflict matrix. For every rule we capture owner, source of truth, business consequence and test method. Rules without an owner should not enter the code because nobody will maintain them after the first sales season.

CPQ without real-time pricing is only a catalogue. In B2B, price depends on customer, region, volume, currency, contract discount, component availability, material cost, minimum margin, service option and delivery date. Oracle emphasizes real-time pricing, multiple price books, channel pricing, promotions and approvals as core CPQ capabilities.

MedusaJS gives a useful base for custom B2B pricing: the Pricing Module supports multi-currency and region prices, price lists, tiers, custom rules and best-price calculation in context. The Product Module supports variants, bundled/multi-part products and tiered pricing. This is not a full enterprise CPQ after installation, but it has the right commerce domains to build on.

The most important rule: pricing must be auditable. Sales, CFO and the B2B customer should understand where the price came from: base list, contract discount, configuration surcharge, component cost, volume discount, currency, transport and margin. If the price is a magic result, the team will not trust the system and will return to Excel.

CPQ should not replace ERP or CAD. ERP usually owns customers, contracts, stock, orders, invoices, material cost and production process. PIM owns descriptions, attributes and product content. CAD or PLM owns engineering data and models. CPQ should orchestrate these sources into a sales decision, not create another copy of truth.

The practical architecture depends on company maturity. If ERP has a stable API, CPQ can read availability, cost and customer status near real time. If ERP is slow or difficult, we build an integration layer and cache with a clear data freshness policy. If CAD/PLM has no API, we start with parameter exports and model version control.

The largest risk is lack of version control. A quote generated on Monday must be reproducible on Friday: which rules, prices, costs and models created it? Without a configuration and price snapshot, every complaint or renegotiation becomes an investigation.

3D is valuable when it reduces buyer uncertainty or sales-support cost. For machinery, built-ins, modular furniture, devices, halls, vehicles and large products, visualization can show proportions, collisions, accessories, material variants and consequences of a choice. For simple products, 3D can become an expensive extra with little decision impact.

WebGL renders interactive 2D and 3D graphics in the browser without plug-ins, using hardware acceleration from the device. BabylonJS provides a useful layer for scenes, materials, cameras, lights, interactions and model imports. In CPQ, the key question is not "does the model rotate?", but whether the visualization matches rules and BOM.

That is why we separate the 3D model from the decision engine. The model shows the configuration result, but it does not decide compatibility. If a user chooses an invalid set, the backend blocks the configuration and explains why. 3D updates after validation; it does not become the source of truth.

The safest MVP scope is one product line, one sales channel and a limited set of rules that create the highest manual cost. Do not start with every product family, every market, full CAD, all discounts and complete production automation. That is a direct path to a year-long project without value on the way.

Release one should prove three things: the user can configure a product without sales support, the system blocks configurations that cannot be manufactured, and price/quote output matches ERP and margin rules. Only then should you add 3D, customer self-service, partner portal, automated approvals, BOM generation, CAD/PLM integrations and more channels.

During DDT we map scope as a tracer bullet: one path from configuration to quote, order and integration. Leadership sees a working process, while the technical team tests the hardest risks early: rules, pricing, ERP, documents and permissions.

CPQ cost is not mostly driven by screen count. It is driven by rule count, product-data quality, ERP/API readiness, number of price lists, approval requirements, quote documents, user roles, languages, currencies, 3D model and whether the system serves customers, sales teams or both.

In practice, a sensible first scope for a B2B manufacturer often starts around PLN 200,000-450,000: DDT, domain model, rules backend, B2B storefront, basic pricing, ERP/PIM integration, quote document, user roles and tests. 3D, CAD/PLM, advanced approvals, partner portal, multi-market support and automated BOM can increase scope meaningfully.

That is why we do not promise a price after one call. First we run DDT: product rules, integrations, data, UX, architecture, risks, MVP priorities and maintenance model. Only then does fixed price make sense because the budget comes from discovered scope, not a hopeful brief.

If you are preparing CPQ, collect these answers before asking for an estimate. They shorten discovery and quickly show whether the project is a configuration, pricing, data, integration, UX or organizational-change problem.

• Which product line has the highest manual quoting cost or the most errors?
• Where do rules live today: ERP, Excel, CAD/PLM, PIM, documentation or engineers knowledge?
• Which rules block production, and which only affect price or delivery date?
• Does ERP expose APIs for customers, stock, price lists, orders and invoices?
• Do you need customer self-service, sales console, partner portal or all of them?
• Must the quote generate BOM, PDF, contract, proforma, order or production task?
• Which roles approve discounts, technical exceptions and non-standard delivery dates?
• Will 3D reduce questions and errors, or is it mainly a marketing layer?

GMI does not start CPQ by choosing a 3D library. We start with sales process, margin, product data, ERP, user roles and manufacturing risk. Only then do we choose technology: MedusaJS for commerce core, NestJS for rules and integrations, Next.js for the portal, PostgreSQL for data, BabylonJS/WebGL for 3D when it genuinely helps sales.

The most important DDT output is a responsibility map: what lives in ERP, CPQ, PIM, CAD/PLM and storefront, and how to reproduce a quote a month later. This map lets us move into fixed price after discovery instead of pretending that manufacturing complexity can be estimated from "3D configurator" alone.

For the client, that means less risk: source-code ownership, no vendor lock-in, integration-ready architecture and a CPQ product that can grow in stages. Release one should deliver a working path: configuration -> price -> quote -> order. Then we scale product lines, channels, markets and automation.