DEV Community: Dominik

The color-change memory leak in Three.js configurators

Dominik — Sun, 01 Nov 2026 09:00:00 +0000

Color pickers are the most-used control in a product configurator. They are also where I shipped my first real GPU memory leak, because the fix for "change the color" looks harmless and is not.

The leak

The intuitive version builds a fresh material every time the user picks a color:

colorPicker.addEventListener('input', (e) => {
  mesh.material = new THREE.MeshStandardMaterial({ color: e.target.value })
})

It works on screen. But the old material is still on the GPU. Three.js does not garbage-collect GPU resources for you. A customer who tries twenty colors has left nineteen materials, and their textures and shader programs, allocated on the graphics card. On a configurator people play with for a few minutes, memory climbs until the tab gets slow or the context is lost.

The fix: reuse the material, set the color

If only the color changes, never build a new material:

colorPicker.addEventListener('input', (e) => {
  mesh.material.color.set(e.target.value)
})

One material for the lifetime of the mesh. The color is a cheap uniform update, not a new GPU allocation. This is also why per-instance color on an InstancedMesh uses setColorAt, not a new material per instance.

When you really do need a new material

Sometimes the change is not just color: a different map, a switch from matte to glossy, transparent to solid. Then you do need a different material, and you must dispose of the old one yourself:

const old = mesh.material
mesh.material = buildMaterial(newOptions)
old.dispose()                 // frees the program and uniforms
old.map?.dispose()            // textures are separate, dispose them too

The rule: .dispose() anything you replace, and do not replace what you can mutate. Color, roughness, metalness, opacity are all live properties. Reach for a new material only when the shader itself has to change.

The decorative lamp configurator at lampy3d.grodev.pl swaps finishes constantly and holds flat memory because of exactly this.

I am Dominik Groński / GroDev, a studio in Poznan, Poland building custom 3D configurators and Laravel back-ends for manufacturers.

CAD to glTF - the manufacturer file pipeline nobody warns you about

Dominik — Fri, 30 Oct 2026 09:00:00 +0000

The demo looks easy: load a glTF, orbit around it, swap a material. Then a real manufacturer sends you their actual product file and you learn that the hard part was never the Three.js. It was getting their CAD into something a browser can load in under three seconds.

What actually arrives

Manufacturers model in SolidWorks, Inventor, Rhino, or hand you a STEP file. Exported to glTF, a single product variant lands at 40 to 120MB. It is usually:

Z-up, because that is the CAD convention. Three.js is Y-up, so your model is lying on its back.
Scaled in millimeters or inches, so it is either microscopic or the size of a building.
Stripped of materials, or carrying CAD materials that mean nothing to a PBR renderer.
Thousands of separate parts, every bolt its own mesh, which is thousands of draw calls.

None of that is the manufacturer doing anything wrong. It is just that CAD and realtime web rendering want opposite things.

The pipeline

I run every incoming model through the same stages before it goes near the configurator:

Decimate and merge in Blender. Collapse the part tree, remove internal geometry the customer never sees, weld bolts and screws into the parent. A 4000-part assembly becomes a handful of meshes.
Fix orientation and scale on import. Rotate Z-up to Y-up, set 1 unit = 1 meter. Do it once, bake it, never think about it again in the app.
Reassign PBR materials by slot. Not per part. Group surfaces into material slots (frame, glass, hardware) so a color picker touches one material, not two hundred.
Compress. gltf-transform or gltf-pipeline with Draco for geometry. For textures, KTX2 so the GPU stores them compressed, not just the file.

gltf-transform optimize in.glb out.glb --compress draco --texture-compress ktx2

90MB in, 2 to 5MB out, with no visible loss on a product shot.

The part the quote forgets

Here is the thing the demo budget never includes: this pipeline is per product line, and it is ongoing. New product, new file, run it again. New variant, new export. If the manufacturer updates a model, someone reprocesses it.

When I scope a configurator I treat the asset pipeline as its own line item, sometimes with a small Blender script or a Laravel queue job so reprocessing is one command, not a day of clicking. The studio runs several of these in production, one per manufacturer, each fed by the same pipeline.

I am Dominik Groński / GroDev, a studio in Poznan, Poland building custom 3D configurators and Laravel back-ends for manufacturers.

Visual CPQ for machine builders: let the customer lay out the cell

Dominik — Fri, 30 Oct 2026 09:00:00 +0000

A machine builder told me their quoting cycle for a production line was three to six weeks. Every enquiry went back to engineering for a drawing, an equipment list and a cost estimate. Meanwhile the customer asked a competitor. That gap is exactly what visual CPQ closes.

I build configurators, including visual CPQ systems for machine builders and line integrators, so here is how it works and when it is worth it.

What visual CPQ actually is

CPQ means Configure, Price, Quote. The visual part means the customer does the configure step themselves, in 3D, in the browser, inside guardrails you define. Instead of describing what they want in an email, they lay out a production cell from your real catalogue: conveyors, a robot, a case packer, whatever your line is built from.

The system then does the work that used to go to engineering first:

Validates the layout for collisions and safety-zone clearances as it is built, so an impossible or unsafe configuration cannot be submitted.
Simulates throughput and shows the bottleneck, so the customer sizes the line correctly.
Returns a priced bill of materials, computed to your rules, plus an engineering-review request.

The result is that engineering receives a complete, buildable specification instead of "how much does a line like this cost".

Why a PDF and an email lose this race

The old cycle fails on timing and on data quality at the same time.

Timing: the customer who can self-serve a validated layout in an afternoon does not wait three weeks. In Maschinenbau, where the buyer is comparing two or three suppliers, the one who answers fastest with real numbers is in front.

Data quality: a free-text enquiry is ambiguous. A configured cell is not. It carries dimensions, equipment, interfaces and constraints, so the quote that comes back is accurate and the project starts without a round of clarifications.

What it connects to

A visual CPQ system is only useful if the output lands where your business already runs. The priced configuration and the bill of materials flow into SAP, a custom ERP, a PLM or your CRM over an API, so the quote and the order carry a full, validated spec. The code runs on your own infrastructure in the EU, and it is yours.

See it running

I built a visual CPQ demonstrator you can click with no sign-up. Drop in conveyors, a robot and a packer, watch the collision checks fire, run the throughput and read the priced bill of materials: factory3d.grodev.pl. The longer write-up for machine builders is on the visual CPQ page, and the full set of configurators is on the main configurator page.

To be straight: that is my own demonstrator, not a client rollout. I show it so the mechanics stop being a promise before anyone pays for a build.

What it costs

Ballpark, so you can judge fit:

From EUR 40,000 for a configurable cell with collision checks, a throughput simulation and a priced bill of materials, wired into your quoting flow.
EUR 60,000 to 120,000+ for a multi-line or multi-plant platform with deep ERP and PLM integration and an operator console.

One fixed price after a scoping call. It is a one-off build you own, which removes the recurring licence that enterprise CPQ platforms charge year after year.

FAQ

Who is visual CPQ for?
Machine builders and line integrators whose quoting bottleneck is engineering time per enquiry, and who lose deals to slower-but-not-really competitors.

Can it really validate collisions and safety zones?
Yes. The layout is checked as the customer places equipment, so unsafe or impossible configurations cannot be submitted. The throughput simulation shows the bottleneck.

Does it replace engineering?
No. It moves the first pass to the customer so engineering starts from a validated specification instead of a blank enquiry. It gives your engineers a head start, not a replacement.

Will it integrate with our PLM and ERP?
Yes, over an API: SAP, a custom ERP, a PLM or your CRM. The code is yours and runs on your infrastructure.

How long does it take to build?
A configurable cell is a few months depending on the equipment library and the rules. A paid pilot on one cell type is a good way to prove it first.

Cut your quoting cycle

Tell me what you build and how you quote it today. I will send a fixed quote within 48h, or an honest "this is not for me". Email: dominik.gronski@grodev.pl

Written by Dominik Groński GroDev, a solo full-stack developer building custom 3D configurators and Laravel back-ends for manufacturers across the EU, UK and US.

Individueller 3D-Konfigurator vs Zakeke, Roomle, Threekit: selbst bauen oder kaufen?

Dominik — Thu, 29 Oct 2026 09:00:00 +0000

Ein Hersteller mit einem Produkt in vielen Varianten stellt mir alle paar Wochen dieselbe Frage: "Soll ich Zakeke, Roomle oder Threekit kaufen oder einen bauen lassen?"

Meine ehrliche Antwort beginnt mit einer Gegenfrage: muss Ihr Konfigurator das Produkt nur zeigen oder es verstehen?

Wenn er es nur zeigen muss (ein Modell drehen, eine Farbe wählen, gut aussehen), kaufen Sie eine SaaS und zahlen nicht zu viel. Wenn er es verstehen muss (nach Ihren Regeln bepreisen, unmögliche Variantenkombinationen blockieren, eine fertige Bestellung in Ihr ERP schieben), kämpft eine Vorlage ewig gegen Sie, und Sie bauen individuell.

Hier die ganze Analyse, mit dem Teil, den die meisten Vergleiche auslassen: die Kosten über drei Jahre.

Die eine Regel, die entscheidet

Fertige Konfiguratoren (Zakeke, Roomle, Threekit, ConfigOne und der Rest) sind sehr gut in der visuellen Ebene. Sie bekommen schnell 3D im Browser, ohne Entwickler. Für ein Standardprodukt, eine einfache Optionsliste und ein kleines Budget ist das das richtige Werkzeug. Ich sage das offen, statt jemandem einen Build zu verkaufen, den er nicht braucht.

Es wird schwierig, sobald Ihre Preise oder Regeln nicht mehr in die Vorlage passen:

Ihr Preis hängt von Mengenstaffeln, Großhandelsstufen und Margen ab, die nicht öffentlich sein sollen.
Option A verändert, was bei Option B möglich ist, und die Kombinationen müssen validiert werden.
Die fertige Konfiguration muss in SAP, ein eigenes ERP oder einen bestimmten Warenkorb, nicht nur in eine E-Mail.

Genau da schlägt "verstehen" das "zeigen", und da rechnet sich individuell.

Build vs Buy im direkten Vergleich

Kriterium	Individueller Build	Fertige SaaS
Zahlungsmodell	Einmaliges Projekt	Abo, dauerhaft
Typischer Preis	Ab ~15.000 EUR einmalig	~8.000 bis 100.000+ EUR pro Jahr
Quellcode	Ihrer, auf Ihrem Repo und Hosting	Keiner, Sie mieten Zugang
Wo der Preis berechnet wird	Serverseitig, nicht in den Devtools sichtbar	Oft clientseitig
Preis- und Variantenregeln	Jede Logik, die Sie beschreiben können	Innerhalb der Vorlage
ERP- / Shop-Anbindung	Beliebig, über eine API	Innerhalb der Konnektoren des Anbieters
Anbieter-Lock-in	Keiner, Daten und Engine sind Ihre	Ja, beides bleibt beim Anbieter

Die Drei-Jahres-Kosten, die auf keiner Preisseite stehen

Das ist die Zahl, die für die meisten mittelständischen Hersteller die Entscheidung dreht.

Eine Enterprise-Konfigurator-SaaS kostet nicht 50 EUR im Monat. Veröffentlichte und geschätzte Spannen liegen zwischen 8.000 und 100.000+ EUR pro Jahr, sobald Sie echte Varianten, Integrationen und Nutzer brauchen. Rechnen Sie das weiter:

Jahr 1: Sie zahlen und haben ein gemietetes Werkzeug.
Jahr 2: Sie zahlen erneut, dasselbe Werkzeug.
Jahr 3: Sie zahlen erneut und besitzen weiterhin nichts.

Ein einmaliger Build ist eine einzige Zahlung plus Hosting (oft ein paar Dutzend Euro im Monat). Der Break-even gegenüber einem Enterprise-Abo liegt meist innerhalb der ersten 12 bis 24 Monate. Danach besitzen Sie einen Vermögenswert statt einer Miete, und eine Preisänderung ist eine Datenänderung auf Ihrem Server, keine neue Lizenzstufe.

Das ist das ganze Argument in einem Satz: mit SaaS zahlen Sie weiter, um Ihren eigenen Konfigurator nutzen zu dürfen.

Die stille technische Falle: clientseitige Preise

Ein Detail entscheidet mehr als das Preisschild. In vielen Plugin-Konfiguratoren wird der Preis im Browser berechnet. Das heißt, Ihre Mengenschwellen, Großhandelspreise und Margen stecken in JavaScript, das jeder in den Devtools öffnen und lesen oder ändern kann.

Ein individueller Build berechnet den Preis serverseitig. Der Browser erhält ein Ergebnis, nie die Preisliste. Für B2B, wo Ihre Nettopreise das sind, was Sie am meisten schützen wollen, ist das kein Nice-to-have. Es ist der Grund zu bauen.

Wann ich zur SaaS rate

Um ehrlich zu bleiben, die Fälle, in denen ich zu einem fertigen Werkzeug rate und keinen Build anbiete:

Das Produkt ist Standard und die Optionen sind einfach.
Sie brauchen es in Tagen, nicht Wochen.
Es gibt kein ERP und keine Preislogik zu integrieren.
Das Budget ist klein und ein Abo ist über Ihren realen Horizont wirklich günstiger.

Wenn das auf Sie zutrifft, erledigen Zakeke oder Roomle den Job. Kein Build nötig.

Sehen Sie die Mechanik, bevor Sie dafür zahlen

Ich baue individuelle 3D-Konfiguratoren und habe zehn davon als Live-Demonstratoren online gestellt, damit die Mechanik kein Versprechen bleibt. Es sind meine eigenen Demos, keine Kundenprojekte, und Sie können jede ohne Anmeldung anklicken:

Ein Pergola-Konfigurator mit Sonnensimulator und Regentest.
Ein Sauna- und Spa-Konfigurator mit kinoreifem nordischem Render.
Visual CPQ für Maschinenbauer: eine Fertigungszelle planen, mit Kollisionsprüfung und bepreister Stückliste.

Das volle Set und der längere Make-or-Buy-Vergleich stehen auf der Hauptseite zum 3D-Produktkonfigurator.

Was ein individueller Build kostet

Richtwerte, damit Sie die Passung vor jedem Gespräch einschätzen können:

Ab 15.000 EUR für eine Produktlinie mit Echtzeit-3D und serverseitiger Live-Kalkulation.
25.000 bis 45.000 EUR mit Variantenkatalog, Abhängigkeitsregeln und einem Admin-Panel, das Ihr Team bedient.
Ab 60.000 EUR für ein Multi-Brand- oder Betreiberportal mit tiefer ERP-Integration.

Ein Festpreis nach einem kurzen Gespräch, keine Spanne mit verstecktem "ab".

FAQ

Ist individuell immer besser als SaaS?
Nein. Für ein Standardprodukt mit einfachen Optionen und ohne Integration ist eine SaaS schneller und günstiger. Individuell gewinnt bei Preisregeln, ERP-Integration, Code-Eigentum und einem mehrjährigen Horizont.

Wie lange dauert ein individueller Build?
Von etwa drei Wochen für eine Produktlinie bis zu einigen Monaten für ein Multi-Brand-Portal. Ein bezahlter Pilot an einem echten Produkt ist ein guter Start.

Wem gehört der Code?
Ihnen, ab dem ersten Commit, auf Ihrem Repository und Hosting. Keine Lizenz, um Ihr eigenes Werkzeug zu nutzen.

Lässt es sich an mein ERP anbinden?
Ja, über eine API: SAP, ein eigenes ERP, PIM, WooCommerce, Shopify oder eine schlanke Seite, die die Bestellung an Ihr CRM übergibt.

Warum serverseitige Preise?
Damit Ihre Staffeln und Margen nie im Browser sichtbar oder editierbar sind. Konfiguratoren, die rein in JavaScript rechnen, haben dieses Problem per Definition.

Build or Buy, für Ihren Fall entschieden

Schicken Sie mir, was Sie verkaufen und wie Sie heute kalkulieren. Ich sage Ihnen ehrlich, ob Sie eine SaaS kaufen oder bauen sollten, und wenn es ein Build ist, einen Festpreis innerhalb von 48 Stunden. E-Mail: dominik.gronski@grodev.pl

Geschrieben von Dominik Groński GroDev, einem Solo-Full-Stack-Entwickler, der individuelle 3D-Konfiguratoren und Laravel-Backends für Hersteller in der EU, UK und den USA baut.

How much does a custom 3D product configurator really cost?

Dominik — Tue, 27 Oct 2026 09:00:00 +0000

"From $300." I see that number on plugin pages and it is the most expensive sentence in the category, because it is the start of a bill, not the end of one.

I build custom 3D product configurators, so people ask me the real number constantly. Here it is, with the parts that actually move it, so you can budget before any call.

The short answer

A custom 3D product configurator, built from scratch and owned by you, lands in these ranges:

From EUR 15,000 for one product line: real-time 3D, server-side live pricing, mobile-tuned, lead or cart output.
EUR 25,000 to 45,000 for a variant catalogue, dependency rules and an admin panel your team runs.
From EUR 60,000 for a multi-brand or operator portal with deep ERP integration and custom logic.

One fixed price after a short call. Not a range with a hidden "from" that grows mid-project.

What actually moves the price

The headline number is set by five things, in roughly this order of impact.

1. Do you have 3D models?

If you already have CAD or 3D files, we start from them and you save real money. If not, there are cheaper paths than a photorealistic render per SKU: a parametric model that resizes, recolours and reconfigures itself (ideal for furniture, joinery, packaging, profile systems), or photos combined with a 2D configuration where full 3D is not worth it. The wrong assumption here, "we need a perfect render of all 800 products", is what blows budgets.

2. How complex is the pricing logic?

A single rate card is cheap. Quantity tiers, wholesale levels, margins, surcharges and dependency rules (option A changes what is possible for option B) are where the engineering sits. This is also where a custom build earns its keep, because a template cannot express rules it was not designed for.

3. What does it integrate with?

A clean page that emails the order is the low end. Pushing a validated order with a full spec into WooCommerce, Shopify, SAP or a custom ERP is more, and worth it, because it removes manual re-entry and the errors that come with it.

4. How many variants and languages?

An unlimited SKU catalogue with an admin panel your staff edit, plus three or four languages for export markets, moves the number up. But it moves it once. A SaaS moves it every year.

5. Server-side pricing

Computing the price on the server (so your margins are never visible in devtools) is a small line item and a large protection. I treat it as default for anything B2B.

Why "from $300" is a trap

A cheap plugin gives you a dropdown and a photo that often does not match the selection. The customer still emails "is it possible to..." and you still answer by hand. Worse, the price usually computes in the browser, so your wholesale tiers sit in JavaScript that anyone can read. The $300 is real. The cost of everything it does not do is the actual bill.

The number that decides it: three-year cost

Compare like for like over a realistic horizon.

	Custom build	Enterprise configurator SaaS
Up front	From EUR 15,000 once	Setup + first year
Year 2	Hosting only (~tens of EUR/mo)	Full subscription again
Year 3	Hosting only	Full subscription again
After 3 years	You own the code	You own nothing

Enterprise configurator subscriptions commonly run EUR 8,000 to 100,000+ per year. The break-even against them usually lands inside the first 12 to 24 months. After that, a custom build is an asset and the SaaS is still a rental.

How to get a real fixed price

Two steps, no guesswork.

A short call: you show the product and its variants, we agree what the customer can change, how the price is calculated and where orders go.
A fixed quote within 48h. If it is a build, I take one product as a paid pilot, with real SKUs and real pricing rules, and ship a working configurator in the browser in about three weeks. The pilot fee counts toward the full build, and the pilot code is yours either way.

You can see what the finished thing looks like first: ten live configurators you can click with no sign-up are on the custom 3D configurator page, including a sauna configurator and a packaging configurator with volume pricing.

FAQ

What is the cheapest a real custom configurator can be?
Around EUR 15,000 for one product line with real-time 3D and live pricing. Below that you are usually buying a plugin, which is fine for a simple, show-only product.

Why not just buy a SaaS?
For a standard product with simple options and no integration, you should. Custom wins on pricing rules, ERP integration, code ownership and a multi-year horizon.

Does the price include the 3D models?
Models are scoped separately and transparently, because the cost depends entirely on what you already have. CAD files make it cheap. Nothing at all means parametric modelling, which I price up front.

Is there any subscription?
No. It is a one-off project plus your own hosting. No per-order commission, no per-view fee.

Who owns the code?
You do, from the first commit, on your repository and hosting.

Get your number

Send me what you sell and how you price it today, and I will send a fixed quote within 48h, with an honest "buy a SaaS instead" if that is the right call. Email: dominik.gronski@grodev.pl

Written by Dominik Groński GroDev, a solo full-stack developer building custom 3D configurators and Laravel back-ends for manufacturers across the EU, UK and US.

Self-host your Draco decoder - the 600ms CDN tax on Three.js configurators

Dominik — Tue, 27 Oct 2026 09:00:00 +0000

Draco compression is the difference between a 90MB glTF export and a 3MB one. For CAD-heavy product models it is not optional. But there is a trap in the standard setup that quietly costs you half a second on first paint.

The default that looks fine

Most examples point the decoder at Google's CDN:

const dracoLoader = new DRACOLoader()
dracoLoader.setDecoderPath('https://www.gstatic.com/draco/v1/decoders/')

It works. It also means every first-time visitor makes a cross-origin trip to fetch the WASM decoder before a single triangle appears. In my measurements on real configurators that added around 600ms to first paint on a cold cache, right at the moment the user is staring at an empty canvas deciding whether to wait.

The fix: self-host the decoder

Copy the decoder out of the Three.js package you already have installed:

node_modules/three/examples/jsm/libs/draco/

Drop it in your public/ folder and point at it:

const dracoLoader = new DRACOLoader()
dracoLoader.setDecoderPath('/draco/')   // served from your own origin

const loader = new GLTFLoader()
loader.setDRACOLoader(dracoLoader)

Now the decoder loads from the same origin, in parallel with the rest of your assets, cached by the same CDN or server rules as everything else. No extra cross-origin handshake on the critical path.

Two things people miss

The decoder is WASM plus a JS wrapper. Copy the whole draco/ folder, not just one file, or you get a confusing "failed to load" with no stack trace.
Set the right cache headers. The decoder never changes between builds. Give it a long Cache-Control: max-age so returning visitors pay nothing. First visit is the only one that touches it.

Small change, measurable win, and it lives on the critical path so it punches above its weight. The pool configurator at basen3d.grodev.pl serves its decoder this way.

I am Dominik Groński / GroDev, a studio in Poznan, Poland building custom 3D configurators and Laravel back-ends for manufacturers.

Custom 3D configurator vs Zakeke, Roomle, Threekit: build or buy?

Dominik — Sat, 24 Oct 2026 18:31:27 +0000

A manufacturer with a product that sells in many variants asks me the same question every few weeks: "Should I buy Zakeke, Roomle or Threekit, or have one built?"

My honest answer starts with a single question back: does your configurator have to show the product, or understand it?

If it only has to show (rotate a model, pick a colour, look nice), buy a SaaS and do not overpay. If it has to understand (price it by your own rules, block impossible variant combinations, push a finished order into your ERP), a template will fight you forever and you build custom.

Here is the full breakdown, with the part most comparison posts skip: the three-year cost.

The one rule that decides it

Off-the-shelf configurators (Zakeke, Roomle, Threekit, ConfigOne and the rest) are very good at the visual layer. You get 3D in the browser fast, with no developer. For a standard product, a simple option list and a small budget, that is the right tool. I tell people this out loud instead of selling them a build they do not need.

They start to hurt the moment your pricing or your rules stop fitting the template:

Your price depends on quantity tiers, wholesale levels and margins you do not want public.
Option A changes what is possible for option B, and the combinations have to be validated.
The finished configuration has to land in SAP, a custom ERP or a specific cart, not just an email.

That is where "understand" beats "show", and where custom pays off.

Build vs buy, side by side

Criterion	Custom build	Off-the-shelf SaaS
Payment model	One-off project	Subscription, forever
Typical price	From ~EUR 15,000 once	~EUR 8,000 to 100,000+ per year
Source code	Yours, on your repo and hosting	None, you rent access
Where price is computed	Server-side, not visible in devtools	Often client-side
Pricing and variant rules	Any logic you can describe	Within the template limits
ERP / shop integration	Any, over an API	Within the vendor's connectors
Vendor lock-in	None, data and engine are yours	Yes, both stay with the vendor

The three-year cost nobody prints on the pricing page

This is the number that flips the decision for most mid-size manufacturers.

An enterprise configurator SaaS is not EUR 50 a month. Published and estimated ranges land somewhere between EUR 8,000 and 100,000+ per year once you need real variants, integrations and seats. Run that forward:

Year 1: you pay, and you have a rented tool.
Year 2: you pay again, same tool.
Year 3: you pay again, and you still own nothing.

A one-off custom build is a single payment plus hosting (often tens of euros a month). The break-even against an enterprise subscription usually lands inside the first 12 to 24 months. After that, you own an asset instead of renting one, and the price list is a data change on your server, not a new licence tier.

That is the whole argument in one line: with SaaS you keep paying to keep using your own configurator.

The quiet technical trap: client-side pricing

One detail decides more than the price tag. In a lot of plug-in configurators, the price is computed in the browser. That means your quantity thresholds, wholesale prices and margins sit in JavaScript that anyone can open in devtools and read, or edit.

A custom build computes the price server-side. The browser receives a result, never the price list. For B2B, where your net prices are the thing you most want to protect, this is not a nice-to-have. It is the reason to build.

When I tell people to buy the SaaS

To keep this honest, the cases where I send people to an off-the-shelf tool and do not pitch a build:

The product is standard and the options are simple.
You need it live in days, not weeks.
There is no ERP or pricing logic to integrate.
The budget is small and a subscription is genuinely cheaper over your real horizon.

If that is you, Zakeke or Roomle will do the job. No build needed.

See the mechanics before you pay for them

I build custom 3D configurators, and I put ten of them online as live demonstrators so the mechanics stop being a promise. They are my own demos, not client work, and you can click any of them with no sign-up:

A bioclimatic pergola configurator with a sun simulator and a rain test.
A sauna and spa configurator with a cinematic Nordic render.
A packaging configurator where the unit price drops with volume and you download a print-ready die-line.
Visual CPQ for machine builders: lay out a production cell, with collision checks and a priced bill of materials.

The full set and the longer build-vs-buy comparison live on the custom 3D configurator page.

What a custom build costs

Ballpark, so you can judge fit before any call:

From EUR 15,000 for one product line with real-time 3D and server-side live pricing.
EUR 25,000 to 45,000 with a variant catalogue, dependency rules and an admin panel your team runs.
From EUR 60,000 for a multi-brand or operator portal with deep ERP integration.

One fixed price after a short call, not a range with a hidden "from".

FAQ

Is a custom configurator always better than SaaS?
No. For a standard product with simple options and no integration, a SaaS is faster and cheaper. Custom wins when pricing rules, ERP integration, code ownership or a multi-year horizon are in play.

How long does a custom build take?
From about three weeks for a single product line to a few months for a multi-brand portal. A paid pilot on one real product is a good way to start.

Who owns the code?
You do. It goes to your repository and your hosting from the first commit. No licence to use your own tool, and you can hand it to another developer any time.

Can it integrate with my ERP?
Yes, over an API: SAP, a custom ERP, PIM, WooCommerce, Shopify or a clean page that pushes the order to your CRM.

Why server-side pricing?
So your wholesale tiers and margins are never visible or editable in the browser. Configurators that price purely in JavaScript have that problem by design.

Build or buy, decided for your case

Send me what you sell and how you price it today. I will tell you honestly whether to buy a SaaS or build custom, and if it is a build, a fixed quote within 48h. Email: dominik.gronski@grodev.pl

Written by Dominik Groński GroDev, a solo full-stack developer building custom 3D configurators and Laravel back-ends for manufacturers across the EU, UK and US.

Custom 3D configurator vs Zakeke or Roomle - when to actually build your own

Dominik — Sat, 24 Oct 2026 09:00:00 +0000

I build custom 3D product configurators for a living, so take this with the obvious grain of salt. But I talk a lot of prospects out of a custom build, because for many of them an off-the-shelf tool is the right answer. Here is how I decide.

When off-the-shelf wins (Zakeke, Roomle, ThreeKit and friends)

Use a SaaS configurator when:

Your product fits a standard parametric model: apparel, furniture with clean options, signage, packaging with print areas.
You want to launch in days, not a quarter.
Your pricing is option-based and simple: base price plus per-option surcharges.
You are fine living inside their data model and their UI.
Your volume does not make the per-seat or per-view fee hurt yet.

If that is you, pay the subscription. You get a maintained renderer, a dashboard, and someone else on call when WebGL breaks on a new iOS version. Rebuilding that yourself is not a flex, it is a cost.

When custom actually pays off

I tell people to build custom when at least one of these is true:

Geometry or rules the SaaS cannot express. Operable wall panels with track-and-stacking logic, cables that need real catenary curves, assemblies where option A changes what is valid for option B. The moment the configurator needs to understand your product, templates run out.
Pricing and lead time live in your systems. If the real price comes from your ERP and the real lead time comes from your production queue, you are going to integrate anyway. At that point the SaaS is a skin you are fighting, not a shortcut.
Deep integration with your stack. WooCommerce, a custom CRM, a Laravel back-office, an ERP. Custom means the configuration flows straight into an order and a work ticket, not a CSV you re-key.
You want to own the data and the UX. No per-view pricing surprise, no vendor roadmap deciding your features, your brand end to end.
The SaaS fee crosses over. Run the math. A four-figure monthly fee for a few years funds a custom build that then costs you only hosting.

The honest crossover

A SaaS configurator is cheaper and faster right up until your product or your process stops fitting the template. Then every workaround costs more than the subscription saved. Custom is the opposite: more upfront, then it bends to whatever you actually sell.

My rule of thumb: if the configurator only has to show the product, buy it. If it has to understand the product, build it. The understanding part - rules, pricing, lead time, integration - is the part I work on, and it is also the part no template ships with.

If you want to see what custom looks like running in production, there are a few live on subdomains of grodev.pl.

I am Dominik Groński / GroDev, a studio in Poznan, Poland building custom 3D configurators and Laravel back-ends for manufacturers.

InstancedMesh in Three.js - one draw call for the parts you repeat

Dominik — Wed, 21 Oct 2026 09:00:00 +0000

A product configurator is full of repeated geometry. A pergola has 40 louvres. A fence has 60 slats. A pool deck has a grid of tiles. The straightforward way to build that, one Mesh per part, is also how your frame rate dies on a mid-range phone.

The naive version

for (let i = 0; i < 40; i++) {
  const louvre = new THREE.Mesh(geometry, material)
  louvre.position.z = i * 0.15
  scene.add(louvre)
}

40 meshes is 40 draw calls, every single frame. Add a tilt slider the user drags and now you are touching 40 objects per frame on top of that. My first pergola configurator sat at 12 FPS on a mid-range Android doing exactly this.

InstancedMesh: one geometry, N transforms, one draw call

const geo = new THREE.BoxGeometry(0.1, 0.02, 3)
const mat = new THREE.MeshStandardMaterial()
const louvres = new THREE.InstancedMesh(geo, mat, 40)

const dummy = new THREE.Object3D()
for (let i = 0; i < 40; i++) {
  dummy.position.set(0, 0, i * 0.15)
  dummy.rotation.x = userTilt
  dummy.updateMatrix()
  louvres.setMatrixAt(i, dummy.matrix)
}
louvres.instanceMatrix.needsUpdate = true
scene.add(louvres)

Same 40 louvres, one draw call. The pergola went from 12 FPS to a locked 60.

Three gotchas that cost me time

dummy.updateMatrix() before setMatrixAt. Forget it and every instance renders at the origin, stacked on top of each other. There is no error, just a mess.
instanceMatrix.needsUpdate = true after you change transforms. Without it the GPU never sees the update. This is the one that makes people decide InstancedMesh is broken and go back to loops.
Per-instance color is setColorAt(i, color) plus instanceColor.needsUpdate = true. Not material.color. If your user picks a color per slat, this is how you do it: one material, N colors, still one draw call.

When it is worth it

Past roughly 100 to 200 repeated objects, or for any repeated object you update every frame. Below that, plain meshes are fine and the code is simpler. Do not instance three cubes to feel clever.

The louvres on pergola3d.grodev.pl run exactly like this. It is one of several things that only show up once a Three.js demo meets a real product catalog, which I wrote more about in lessons from 9 configurator deployments.

I am Dominik Groński / GroDev, a studio in Poznan, Poland building custom 3D configurators and Laravel back-ends for manufacturers.

Turning a 3D configurator into a real quote - price and lead time, not just a pretty model

Dominik — Sat, 17 Oct 2026 19:53:31 +0000

Most Three.js configurator demos stop at the visual. The customer rotates a nice model, picks a color, and that is the whole show. But the manufacturers I build for do not sell models. They sell a product with a price and a delivery date.

The question that closes a sale is not "does it look good". It is "what does THIS configuration cost, and when do I get it". That second half is the part nobody puts in a demo. Here is how I build it.

The configuration is the only thing that matters

The whole system hangs off one structured object: the config. Not the price, not the Three.js scene state. Just the choices the customer made.

const config = {
  product: 'horizon',
  width_mm: 4200,
  height_mm: 2800,
  panels: 6,
  glass: 'frosted',
  finish: 'anodized-black',
  soundproofing: 'acoustic-42db',
  track: 'top-hung',
}

Everything else is derived from this, server-side. The browser owns the preview. The server owns the truth. I wrote about why a client-side price is a 5-second DevTools hack in a separate post. The exact same principle applies to lead time: never let the page be the source of a number the customer acts on.

Price is a server-side function of config

Price is the easy half. Given a raw config, the backend recalculates from scratch and ignores whatever the frontend thinks:

function calculateFinalPrice(array $config): float {
  $price  = self::BASE_PRICE[$config['product']];
  $price += self::GLASS_PRICING[$config['glass']] ?? 0;
  $price += ($config['width_mm'] * $config['height_mm'] / 1_000_000) * self::PER_SQ_METER;
  $price += self::SOUNDPROOFING[$config['soundproofing']] ?? 0;
  return round($price, 2);
}

The frontend still shows a live estimate as the customer drags sliders, because that is good UX. It is just labeled an estimate, and it is never what gets charged.

Lead time is pricing's harder cousin

Price is mostly a lookup plus arithmetic. Lead time depends on moving parts:

base production time per product line
option surcharges (custom glass adds days, acoustic seals add more)
stock components vs made-to-order
the factory's current backlog

Model it as rules, server-side, the same way as price:

function leadTimeDays(array $config, Capacity $cap): int {
  $days  = self::BASE_LEAD[$config['product']];
  if ($config['glass'] === 'custom')                       $days += 10;
  if (str_starts_with($config['soundproofing'], 'acoustic')) $days += 5;
  // queue pressure from live capacity, not a hardcoded guess
  $days += $cap->currentBacklogDays();
  return $days;
}

That currentBacklogDays() is what makes the number real. A hardcoded "4 to 6 weeks" becomes a lie the moment the factory is busy. If the manufacturer can feed you a backlog figure, even a weekly spreadsheet export or a single field in an admin panel, the lead time stops being marketing and becomes a commitment the customer can plan around.

The output is a quote, not a number

The customer configured something real. Give them something to act on:

the price (server-calculated)
the lead time (server-calculated)
a snapshot of their exact configuration: the 3D view rendered to an image, plus the spec list
a reference id, so sales and the customer talk about the same thing

That is a quote. Generate it as a PDF or an order record, email it, and the configurator just did a salesperson's first hour of work before anyone picked up the phone.

This is the 80% nobody demos

The visual is 2 to 3 weeks of work. The quote engine (pricing rules, lead-time rules, a capacity input, PDF or order generation, and an admin UI for the manufacturer to maintain all of it) is the larger half. It is also the half that turns a toy into a tool. When I quote a configurator project, I price the engine, not the screens.

Live configurators if you want to see the visual foundation this sits on:

pergola3d.grodev.pl - bioclimatic pergola, instanced louvres
basen3d.grodev.pl - pool configurator with Draco and PWA

I am Dominik Groński / GroDev, a studio in Poznan, Poland building custom 3D configurators and Laravel back-ends for manufacturers. If you are putting a price and a lead time behind a configurator, that back half is the part I work on.

Why your three.js scene gets a bad PageSpeed score (and it is not JavaScript)

Dominik — Mon, 28 Sep 2026 07:51:18 +0000

Originally published on grodev.pl.

Your 3D scene runs smoothly on your machine. Sixty frames, no jank. You drop the page into PageSpeed Insights and get a 48. Total Blocking Time is red, and the main-thread breakdown shows one long task blamed on gsap.min.js. The first instinct is "too much JavaScript" or "too many particles". Both are almost always wrong, and chasing them can eat a whole day.

This post is the diagnosis, not the recipe. I will show you why a heavy three.js scene scores badly in PageSpeed and where the cost really sits.

PageSpeed has no GPU

This is the key that changes everything else, so start here. Google does not measure your page on a graphics card. Lighthouse and PageSpeed run headless Chrome where WebGL goes through software rendering on the CPU (SwiftShader). Your scene, which takes a fraction of a millisecond on your GPU, runs on the CPU on Google's machine.

You can confirm it with one read of the renderer name. If WEBGL_debug_renderer_info returns swiftshader, llvmpipe, softpipe or software, you are in that mode. Real users on virtual machines and weak hardware get the same. As long as you measure on your own card, you are not seeing what Google sees.

Why it is not JavaScript

In the main-thread breakdown you look at categories: "Script Evaluation", "Style & Layout", "Other". With a heavy WebGL scene, "Other" can be bigger than "Script Evaluation". That is not a bucket to ignore. Other is usually the GPU work and pixel scans, which a script profile does not show at all.

Then there is the misleading label. A long task tagged gsap.min.js or requestAnimationFrame is usually not GSAP. In one frame, every requestAnimationFrame call lands in a single task that takes the label of whoever started it. The GSAP ticker registers first, so it takes the blame for someone else's work. Optimizing GSAP here is aiming at the wrong target.

The first frame is the most expensive frame

A scene usually draws one frame on start and then waits for the user to move. Google's measurement does not move the mouse, so it sees exactly that one frame. And that one frame compiles every shader program at once.

On one of my production builds the scene had fourteen programs: particles, arcs, several bloom layers, composite, output. Each compiled in the first frame, and after every compile the library asked the card for the result. Every such query waits until the card has worked through its whole command queue. The result: one 656 ms task on Google's machine and a score of 73 on desktop. Total Blocking Time sat around 700 ms. None of it was JavaScript in the sense most guides mean.

Cutting particles does not help, and it ruins mobile

The most common reflex is to lower the particle count "for performance". That misreads the problem on two levels.

First, particles are cheap. A point is one vertex. What is expensive is fill: bloom, transparency, overdraw, not the number of points. Cut the particles and you cut the cheap resource while leaving the expensive one untouched.

Second, an image made of particles has a resolution equal to their count. Text built from ten thousand particles looks different from the same text built from seventy thousand. When you give the phone ten times fewer particles "to make it lighter", the text goes blurry or sparse, and you still have not touched the real cost. On one build I raised the phone particle count from seven thousand to seventy-two thousand and the text finally looked sharp, while the score did not drop, because the problem was never the point count.

How to measure without chasing noise

Before you fix anything, you need a measurement that does not lie. Here are the three traps almost everyone falls into.

What you do	Why it lies	What to do instead
Profile in DevTools on your own GPU	The second load has the programs cached on disk, the compilation disappears	A fresh profile with no cache, software rendering (`--disable-gpu`)
A single PageSpeed run	Noise of 7 to 10 points, the same file gives 80 and 95	Median of three, a 7-point significance threshold
Looking at categories instead of tasks	"Other" tells you nothing about the cause	Read the list of long tasks with their start times

The rule is simple. Measure in Google's conditions, not on your card. Read specific tasks, not categories. Treat a change smaller than seven points as chance, not success. Only with a measurement like that does it make sense to touch the scene.

What to do about it

The fix exists and it is repeatable. In short: the first frame must not compile programs, so you compile them ahead of time and warm them up in the background, in the right render conditions. Pixel loops and scene building cannot sit in one task at load. The phone gets the same particle count, only the shots without text are lighter. On the same build where I started at 73, I ended at 97 on desktop, with Total Blocking Time cut from 700 to 140 ms and the first frame from 656 ms to a few milliseconds, with no change to how the scene looks.

I packaged the full method, with copy-ready code, a measurement protocol and a PageSpeed script, as a ready-made skill for developers and coding agents. If you would rather hand the work to me, send the scene URL and I will tell you plainly where the cost sits and how much I will take off.

FAQ

Does a bad PageSpeed score on a WebGL scene hurt my Google ranking?
Google ranks mostly on field data from real users (Core Web Vitals: LCP, CLS, INP), not on the lab score. A <canvas> is not an LCP candidate, so a WebGL scene does not hurt LCP. It does hurt Total Blocking Time, a lab metric, and real INP if the scene blocks the thread during interaction. Worth fixing for the user and the score, without panic that one red lab number sinks the page.

Why is the long task labelled GSAP when I barely use GSAP?
Because a long task label points to the script that started it, not the one that did the work. All requestAnimationFrame calls in a frame go in one task and take the name of the first. The GSAP ticker registers early, so it takes the blame. The real weight is usually shader compilation in the first frame. Do not optimize GSAP on that basis.

Can I just move the scene to a Web Worker or OffscreenCanvas?
Usually not, and usually not as the first move. A Web Worker is a day of work, while the problem is most often solved by task ordering and compiling programs ahead of time, a change of a few hours. Reach for a Worker when you genuinely have heavy CPU work in the render loop, not to hide shader compilation from the measurement.

Can it be fixed without changing how the scene looks?
Yes, and that is the whole point. The method keeps the desktop image untouched to the percent, and the phone just as sharp, only smaller. It is about order and the way things are drawn, when programs compile and what sits in the first frame, not about cutting graphics.

Server-side pricing in Three.js configurators - why client-side gets DevTools-hacked

Dominik — Fri, 04 Sep 2026 17:52:51 +0000

The setup that looks fine

You build a 3D product configurator in Three.js. User picks material, size, options - and next to the model, a live price updates as they configure. The frontend calculates it because that is fast, feels responsive, and does not need a network trip.

The code looks like this:

function calculatePrice(config) {
  let price = BASE_PRICE;
  price += MATERIAL_PRICING[config.material];
  price += config.width * config.height * PER_SQ_METER;
  return price;
}

// Live update on any config change
someSlider.addEventListener('input', () => {
  state.config = readConfig();
  state.price = calculatePrice(state.config);
  updatePriceDisplay(state.price);
});

// On order submission, send the whole state
function submitOrder() {
  fetch('/api/orders', {
    method: 'POST',
    body: JSON.stringify(state)
  });
}

This is what most tutorials show. It is also what I shipped in my first configurator.

The obvious problem I missed

A user opens DevTools. window.state.price = 1. Clicks 'Buy'. Order goes to my backend with price = 1. Backend has no independent pricing logic - it trusts what the frontend sends.

This is not paranoia. This is a 5-second exploit that anyone with basic browser knowledge can do. I caught it because a friend I asked to test the configurator did exactly this within 20 seconds of opening the page.

The fix that is actually secure

Separate two responsibilities:

Frontend: preview the price. This is UX, not truth.
Backend: calculate the final price from raw config, independently. This is truth.

// Frontend - preview only
function previewPrice(config) {
  // Same math as before, but purely for display
  // Explicitly labeled 'estimate' in UI
}

function submitOrder() {
  fetch('/api/orders', {
    method: 'POST',
    body: JSON.stringify({ config: state.config }) // No price sent
  });
}

// Backend - authoritative
function calculateFinalPrice(array $config): float {
  $price = self::BASE_PRICE;
  $price += self::MATERIAL_PRICING[$config['material']] ?? throw new \InvalidArgumentException();
  $price += $config['width'] * $config['height'] * self::PER_SQ_METER;
  return $price;
}

Frontend never sends price. Backend never trusts frontend price. If someone hacks the DevTools price display, they only change what they see - the order still calculates correctly server-side.

The 'but performance' objection

One network trip per configuration change would kill UX. So do not do that. Frontend preview stays instant (client-side math), but is labeled 'preview' or 'estimate'. Backend calculation happens ONCE, at order submission. User never waits during configuration.

Add a 'Confirm order' step where the real price is fetched from backend and displayed for confirmation - so there is no surprise between what they saw and what they pay. This is the pattern Bagisto, Shopify custom apps and Zakeke all use.

The gotcha with variant validation

Same principle applies to configuration validity. Frontend might allow user to set impossible combinations (glass thickness 20mm with hinge type 'lightweight'). Backend must validate independently and reject.

I keep validation logic in a shared JSON schema (JSON Schema draft-07) that both frontend and backend read. Frontend uses it for real-time feedback. Backend uses it as the final gate.

{
  "if": { "properties": { "thickness": { "minimum": 15 } } },
  "then": { "properties": { "hinge": { "enum": ["heavy-duty"] } } }
}

One source of truth. Both sides read it. Backend is authoritative on submission.

Reference implementation

My starter threejs-product-configurator-starter has the frontend preview pattern wired in. Backend calculator is not in the starter (it is deliberately frontend-only for education), but the client-side code is structured so that adding server-side pricing later is a one-file change.

The pricing question is one of five I hit building configurators. The full list is in my 4programmers.net Polish-language thread - WebGL context leaks, material vs new material for color changes, pixel ratio caps for 4K, OrbitControls vs TrackballControls for touch. Different post, same theme: things Three.js tutorials skip.

I am Dominik Groński / GroDev - a studio in Poznań, Poland, building custom 3D configurators and Laravel panels for manufacturers.