# Building a Generative Jewelry Configurator with Vanilla JS, SVG, and Numerology > Source: > Published: 2026-06-22 01:41:38+00:00 published: false description: How GemStudio 360™ turns a name and a birth date into a one-of-a-kind, hand-crafted bracelet — and why we built the rendering engine without a single framework. tags: javascript, svg, pwa, webdev cover_image: canonical_url: [https://lochness-paris.com/configurateur-de-bracelet.html](https://lochness-paris.com/configurateur-de-bracelet.html) A few months ago we set out to build something that doesn't fit neatly into the usual "product configurator" template: a tool that turns your name and birth date into a personalized gemstone bracelet, lets you fine-tune every single bead by hand, and ends with a real artisan crafting the physical piece. Turn an identity (first name, last name, birth date) into 8 symbolic gemstones, let the user build a real bracelet around them bead by bead, and hand the final design off to a craftsperson. No accounts, no backend database of users, no checkout — just a fast, installable web app that ends in a personalized request sent to a human artisan. Why no framework? This was a deliberate choice. The whole app — numerology engine, SVG bead renderer, drag-to-build canvas, smart suggestions, cart — is built in vanilla JavaScript, plain CSS, and a single HTML file. Three reasons drove that decision: Load time matters more than developer convenience here. A big chunk of traffic comes from organic/mobile search for terms like "bracelet chemin de vie." Every extra hundred kilobytes of framework runtime is a few more bounces. The DOM tree is genuinely simple. Four tabs, one SVG canvas, a handful of lists. State management doesn't need a library when the state is "an ordered array of beads plus some UI flags." PWA installability and offline behavior are easier to reason about when you fully control the bootstrapping sequence instead of going through a framework's hydration lifecycle. That said — vanilla JS at this scale means you have to be disciplined about state, which brings us to the next point. State management without a framework The entire bracelet is represented as an ordered array of bead objects. Every mutation (add, remove, reorder, change size) goes through a small set of functions that: update the array, push the previous state onto an undo stack, re-render only the parts of the SVG that changed. That last point matters a lot for performance: with up to ~19 beads rendered as gradient-filled SVG circles, a naive full re-render on every drag event is noticeable on mid-range phones. Re-rendering only the affected bead (and recalculating positions trigonometrically around the guide circle) keeps things smooth. ``` // Simplified illustration of bead positioning on the guide circle function getBeadPosition(index, total, radius, center) { const angle = (index / total) * 2 * Math.PI - Math.PI / 2; return { x: center.x + radius * Math.cos(angle), y: center.y + radius * Math.sin(angle), }; } ``` Undo/redo is just two stacks of array snapshots — simple, but it's the kind of "boring technology" that makes a configurator feel trustworthy. Users mis-click constantly; cheap undo is a UX feature, not a nice-to-have. Generating gemstones instead of photographing them This is the part I find most interesting. With 70+ stone types in the catalog, maintaining a photo library (multiple angles, lighting consistency, file size, retina variants…) would have been a maintenance nightmare. Instead, every bead is a procedurally generated SVG. Each stone type has a "preset" describing its visual family (translucent crystal, opaque mineral, banded stone, metallic finish…), and each individual bead instance gets a random seed that introduces small variations — hue jitter, gradient stop shifts — so that no two beads of the same stone type look perfectly identical, the same way no two real gemstones do. A heavily simplified version of the idea: ``` js function renderBead({ id, baseHue, seed }) { const rng = seededRandom(seed); const hue = baseHue + (rng() - 0.5) * 12; // small natural variation return ` `; } ``` The production renderer is considerably more involved — it layers multiple gradients, clip paths, and noise patterns per mineral family to approximate veining (think lapis lazuli or labradorite) and translucency — but the core trick is the same: vector + seed beats a static image library when you need infinite, lightweight variation. The numerology layer The app's signature feature is the "Life Path Bracelet": you type in a first name and a birth date, and the engine computes 8 symbolic stones — Foundation, Summit, Life Path, Calling, Personality, Expression, Final Touch, and Wish — each tied to a different facet of numerology. I won't detail the letter-to-number mapping or reduction rules here since that's the proprietary core of the product, but structurally it's a pure function: ``` identity (name + date) → numeric reduction → archetype (1–9) → stone(s) ``` Keeping it as a pure, side-effect-free transformation made it trivial to unit test and to keep completely decoupled from the rendering and cart logic. The numerology module has no idea an SVG even exists. Smart suggestions and the "litho score" Beyond manual bead-picking, there's a "Smart" tab with: Harmonious palettes — pre-grouped stones by color coherence, Predefined themes — ready-made compositions for intents like "protection" or "calm," A coherence score that evaluates how energetically consistent a user's manual selection is. These are all derived/precomputed layers sitting on top of the same stone catalog — no real-time AI inference, just well-structured data and some scoring heuristics. It's a good reminder that "smart suggestions" don't always need a model; sometimes a well-curated lookup table does the job at a fraction of the latency and cost. PWA bits that actually mattered A few small, unglamorous details ended up making a real difference on mobile: `touch-action: manipulation` on all interactive elements to kill the old 300ms tap delay. Loading the webfont with `media="print"` then switching to `all` on load, so it never blocks first paint. A Service Worker caching static assets for offline resilience and faster repeat visits. A `manifest.json` so the app can be installed straight from the browser, no app store round-trip. None of this is novel, but it's the kind of checklist that's easy to skip under deadline pressure — and it's exactly the stuff that determines whether a configurator feels like an app or like a website pretending to be one. From pixels to a physical object The configurator deliberately doesn't end in a checkout button. Once a composition is validated, the user lands on a recap + contact form, and the actual fulfillment is handled by a human artisan partner who crafts the bracelet by hand using the validated design as a spec sheet. That constraint shaped a lot of UI decisions — for instance, the cart view always shows an estimated price range rather than a fixed price, since the final quote depends on material choices (precious metal findings, natural pearls, etc.) confirmed with the artisan. What's public, what isn't We open-sourced the documentation and architecture of this project, along with a few deliberately simplified code examples, in a public GitHub repo. What you'll find there: a full architecture breakdown (diagrams included), a feature-by-feature functional spec, simplified illustrative examples of the numerology pattern and the SVG bead rendering pattern (not the production algorithms), a roadmap and contribution guidelines. What stays closed: the actual numerology letter/reduction tables, the full multi-preset rendering engine, the complete stone catalog, and the litho-score algorithm — those remain Loch Ness®'s IP. Try it The live configurator is here: lochness-paris.com/configurateur-de-bracelet.html The project is also archived and citable via Zenodo: zenodo.org/records/19836838 If you're into vanilla-JS architecture, generative SVG, or PWA details, I'd genuinely love feedback — open an issue on the repo or drop a comment below.