How I use Claude to spec a 3D configurator before writing any Three.js

The Three.js in a product configurator is the part everyone looks at. It is also the part that rarely goes wrong. What goes wrong is the modeling: turning a manufacturer's catalog, with its exceptions and "oh, that option only works with this frame", into a clean option model, a set of validation rules, and a pricing schema. I do that part with Claude before I write a line of Three.js, and it has changed how these projects start.

The input is always a mess

A manufacturer sends a PDF brochure, a price list spreadsheet, and a few emails of clarifications. Four product lines, dozens of options, a web of "valid with" and "not available for" rules buried in prose. Reading that into a data model by hand is slow and I always miss a rule.

What I ask Claude to produce

I give it the raw material and ask for structure, not code:

• An option model. Every product, every option group, every value, as a schema I can drop into the database.
• A validity matrix. Which combinations are allowed, surfaced from the prose rules, with the ambiguous ones flagged as questions for the client instead of guessed.
• A pricing skeleton. The rules as pseudocode: base, surcharges, per-unit math, so I can see the shape before I write the PHP.
• The open questions. The single most useful output. The list of "the brochure does not say what happens when X and Y are both selected" that I send straight back to the manufacturer.

That last one is the difference between a spec and a guess. The rules a human skims past are exactly the ones that break a configurator in production.

Then the code is almost boring

Once the option model and rules are agreed with the client, the Three.js and the Laravel are the straightforward part. The scene loads the model, the options map to what the schema already defined, the server-side pricing implements rules that are already written down. The thinking happened up front, in plain language, where it is cheap to change.

This is not "AI writes my app". It is using a language model for the thing language models are actually good at: turning unstructured human description into structured rules, and telling me what the description left out. I document this way of working in every repo, which I wrote about separately.

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