Building a Generative Jewelry Configurator with Vanilla JS, SVG, and Numerology

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
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.

Loch Ness : Système Algorithmique de Détermination Archétypale et de Synergies Minérales à Géométrie Variable. | Zenodo

Résumé du Concept (Abstract) Le projet Loch Ness redéfinit l'interaction entre la psychologie individuelle et la lithothérapie à travers une interface numérique propriétaire. Contrairement aux approches standardisées à sortie fixe, ce concept repose sur deux piliers innovants : une taxonomie archétypale originale et un algorithme de séquençage minéral à géométrie variable. 1. L'Ontologie du « Monstre Noble » Le système utilise une taxonomie d'archétypes originaux créés pour refléter la complexité de la psyché humaine, incluant ses parts d'ombre et sa puissance brute. L'utilisateur n'est pas classé selon des critères sociologiques ou démographiques classiques, mais selon sa « nature sauvage » et sa capacité à canaliser une force intérieure singulière. Cette classification produit, pour chaque profil, un vecteur multidimensionnel d'intensité plutôt qu'une étiquette unique. 2. L'Algorithme de Calcul à Géométrie Variable L'application traite les données de l'utilisateur pour générer une réponse minérale dont la structure est unique à chaque profil : Séquençage Dynamique — le nombre de pierres (de 3 à 8 unités) n'est pas fixe ; il est déterminé par l'algorithme en fonction de la « densité » calculée du profil archétypal. Synergie de Compensation — chaque pierre est sélectionnée pour remplir un rôle fonctionnel spécifique (Ancre, Cœur, Mental, Bouclier, Élan), créant une armure vibratoire sur mesure plutôt qu'un assemblage arbitraire. Cette indirection rôle → pierre permet de faire évoluer indépendamment la nomenclature des rôles et le catalogue minéral, sans recalibrer l'ensemble du système à chaque ajout. 3. Pipeline Algorithmique Le traitement repose sur un pipeline en trois étapes fonctionnelles strictement découplées, chacune testable indépendamment : Normalisation identitaire — les données d'identité (prénom(s), nom, date de naissance) sont transformées en un vecteur de profil multidimensionnel (intensité, part d'ombre, élan, stabilité), sans dépendance au rendu ni à l'interface. Calcul de densité et résolution du nombre de slots — une fonction de densité agrège le vecteur de profil en un score scalaire, ensuite projeté sur l'intervalle entier [3, 8] pour déterminer dynamiquement la longueur de la séquence minérale. Résolution des rôles puis sélection minérale — pour chaque slot, un rôle fonctionnel est résolu en premier (Ancre, Cœur, Mental, Bouclier, Élan), puis une pierre est sélectionnée dans le catalogue pour satisfaire ce rôle au regard du vecteur de profil. 4. Architecture Logicielle Le système est implémenté comme une application web monopage (SPA statique), sans dépendance à un framework JavaScript, avec les caractéristiques techniques suivantes : Stack — HTML5, CSS3 (custom properties), JavaScript natif (vanilla) ; aucune dépendance à un framework de rendu. Moteur de rendu génératif — chaque minéral du catalogue est rendu en SVG généré dynamiquement (gradients radiaux, filtres, clip-paths) à partir d'un identifiant de minéral (« preset ») et d'une graine aléatoire (« seed ») propre à chaque occurrence, simulant veinage, translucidité et inclusions sans recourir à une banque d'images statiques. Disposition géométrique dynamique — la position de chaque pierre sur le support (bracelet) est calculée trigonométriquement en fonction de son index et du nombre total de slots résolu par l'algorithme (N variable, et non une constante), avec mise à l'échelle automatique de la taille des perles selon la densité de la séquence. Gestion d'état — l'état de la composition est représenté par un tableau ordonné de perles, avec piles d'historique (undo/redo) et re-rendu ciblé (et non un re-rendu complet) à chaque mutation, pour préserver la fluidité sur mobile. Progressive Web App — manifeste d'installation (icônes, couleur de thème, mode standalone) et Service Worker assurant la mise en cache des ressources statiques et une résilience hors-ligne partielle. Données structurées — balisage Schema.org (SoftwareApplication, FAQPage) pour l'indexation enrichie, en complément du contenu HTML visible. La documentation d'architecture complète (diagrammes de flux, choix techniques justifiés) ainsi que des exemples de code simplifiés à but pédagogique sont publiés séparément. Les tables de normalisation réelles, la fonction de densité, les seuils de résolution des rôles et le catalogue minéral complet ne sont pas publiés et constituent le cœur propriétaire du système. Objectif du Dépôt Ce document consigne la propriété intellectuelle de la logique algorithmique, de la nomenclature des archétypes et de la méthodologie de sélection des minéraux associée à la marque Loch Ness. Il protège l'invention d'un système de personnalisation où la technologie devient le pont entre l'identité profonde de l'individu et l'objet talismanique. Application en ligne : lochness-paris.com/configurateur-de-bracelet.html

zenodo.org

The result is GemStudio 360™, the engine behind Loch Ness Paris' bracelet configurator. This post walks through the architecture, the technical trade-offs, and a few of the more interesting problems we had to solve — without giving away the proprietary parts (the numerology algorithm and the full gem-rendering engine stay closed source, but the shape of the system is worth sharing).
If you want to dig deeper, the architecture documentation and a few simplified code examples are public on GitHub: application-configurateur-de-bracelets-en-pierres-fines.
The brief, in one sentence

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:

function renderBead({ id, baseHue, seed }) {
  const rng = seededRandom(seed);
  const hue = baseHue + (rng() - 0.5) * 12; // small natural variation

  return `
    <radialGradient id="grad-${id}" cx="40%" cy="35%" r="65%">
      <stop offset="0%"  stop-color="hsla(${hue}, 45%, 75%, 1)" />
      <stop offset="60%" stop-color="hsla(${hue}, 45%, 55%, 1)" />
      <stop offset="100%" stop-color="hsla(${hue}, 45%, 35%, 1)" />
    </radialGradient>
    <circle cx="50" cy="50" r="48" fill="url(#grad-${id})" />
  `;
}

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.