DEV Community: Camille Guerineau

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

Camille Guerineau — Mon, 22 Jun 2026 01:41:38 +0000

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.

How I Built the Two Missing Payload CMS v3 Plugins — Reviews, JSON-LD & Real Production Bugs

Camille Guerineau — Tue, 16 Jun 2026 03:35:50 +0000

Running 23 European e-commerce shops on Payload CMS v3 taught me that some things simply don't exist yet. So I built them.

Background
I maintain a multi-clone e-commerce infrastructure — 23 Next.js + Payload CMS v3 shops deployed across Europe, each on its own subdomain and language. Think fr.myshop.com, de.myshop.com, sk.myshop.com... all running on the same codebase with country-specific patches.
While building this, I kept running into two missing pieces that no one had published for Payload v3:
A customer reviews system with admin moderation and Google star ratings
Complete Schema.org JSON-LD for Google rich snippets (Product, BreadcrumbList, ItemList, AggregateRating)

Both are now published on npm. Here's what I built, the bugs I hit, and how I solved them.

Part 1 — The Reviews Plugin
What didn't exist
Search npm for payload reviews or payload ratings — you'll find nothing for v3. The official plugin ecosystem covers SEO, forms, redirects, Stripe... but not customer reviews.
Building the collection
The reviews collection itself is straightforward — relationship to products, rating (1-5), status select (pending/approved/rejected), author fields. The tricky parts came later.
Access control gotcha: Payload v3 uses a roles array, not a role string. This breaks if you copy v2 patterns:

// ❌ Wrong — always returns false
update: ({ req }) => req.user?.role === 'admin',

// ✅ Correct for v3
update: ({ req }) => req.user?.roles?.includes('admin'),

Prevent self-verification: Users can POST any field on create: () => true collections. Lock verified in a beforeChange hook:

hooks: {
  beforeChange: [
    ({ data }) => {
      if (!data.status) data.status = 'pending'
      data.verified = false // admin-only, always reset on create
      return data
    },
  ],
},

Email protection: read: () => true on the collection exposes authorEmail in the public API. Add field-level access:

{
  name: 'authorEmail',
  type: 'email',
  access: { read: ({ req }) => req.user?.roles?.includes('admin') },
}

The relationship bug — "108 0" instead of 108
When the form submitted product: productId, Payload rejected it with:

"This relationship field has the following invalid relationships: 108 0"

The string "108 0" was being sent instead of the number 108. The fix:

// ❌ Sends "108 0" — unknown why the space appears
body: JSON.stringify({ ...form, product: productId })

// ✅ Force integer
body: JSON.stringify({ ...form, product: parseInt(productId, 10) })

Custom endpoints don't work for parameterized routes in v3
I tried registering the reviews GET endpoint in payload.config.ts:

endpoints: [{ path: '/reviews/product/:productId', method: 'get', handler: ... }]

Result: Route not found "/api/reviews/product/108" — Payload v3 doesn't mount parameterized endpoints correctly under /api.
Solution: use a Next.js App Router route instead:

// src/app/(app)/api/reviews/product/[productId]/route.ts
export async function GET(req, { params }) {
  const { productId } = await params
  const payload = await getPayload({ config: configPromise })
  const reviews = await payload.find({
    collection: 'reviews',
    where: {
      and: [
        { product: { equals: parseInt(productId, 10) } },
        { status: { equals: 'approved' } },
      ],
    },
  })
  // ...
}

The database table doesn't auto-create
Payload running with migration batch: -1 (dev mode) won't auto-migrate on build. You need to create the reviews table manually:

CREATE TYPE "public"."enum_reviews_status" AS ENUM('pending', 'approved', 'rejected');

CREATE TABLE IF NOT EXISTS "reviews" (
  "id" serial PRIMARY KEY,
  "product_id" integer NOT NULL REFERENCES "products"("id") ON DELETE SET NULL,
  "author_name" varchar NOT NULL,
  "author_email" varchar NOT NULL,
  "rating" numeric NOT NULL,
  "title" varchar,
  "comment" varchar NOT NULL,
  "verified" boolean DEFAULT false,
  "status" "enum_reviews_status" DEFAULT 'pending',
  "updated_at" timestamp(3) with time zone NOT NULL DEFAULT now(),
  "created_at" timestamp(3) with time zone NOT NULL DEFAULT now()
);

ALTER TABLE "payload_locked_documents_rels"
  ADD COLUMN IF NOT EXISTS "reviews_id" integer REFERENCES "reviews"("id") ON DELETE CASCADE;

Install

npm install payload-plugin-reviews

// payload.config.ts
import { reviewsPlugin } from 'payload-plugin-reviews'

export default buildConfig({
  plugins: [reviewsPlugin({ productsCollection: 'products' })],
})

→ payload-plugin-reviews on npm

→ GitHub

Part 2 — The JSON-LD Plugin
What didn't exist
Payload's official SEO plugin handles meta tags. It does not handle Schema.org structured data. No one had published a complete JSON-LD solution for Payload v3 e-commerce either.
After running 23 shops in production and passing Google Rich Results validation on all of them, I extracted the patterns into payload-plugin-seo-jsonld.
Bug 1 — price vs lowPrice
Google's Rich Results validator rejects AggregateOffer with price. It requires lowPrice:

// ❌ Google rejects this
offers: { '@type': 'AggregateOffer', price: price }

// ✅ Google accepts this
offers: { '@type': 'AggregateOffer', lowPrice: price }

Bug 2 — Prices stored in cents
Payload e-commerce stores prices in cents (3990 = €39.90). Pass the raw value to Google and you'll have a €3,990 bracelet in your rich snippets:

// ❌ Sends 3990 to Google
lowPrice: product.priceInUSD

// ✅ Correct
lowPrice: (product.priceInUSD / 100).toFixed(2)

Bug 3 — ItemList duplicates crash Google validation
If a page has two ItemList JSON-LD scripts, Google invalidates both. This happened on shops that inherited a carousel from a base template and then had a new one patched in.
The plugin returns null when products are empty, and the pattern makes the single-instance contract explicit:

// Returns null if empty — safe conditional render
const itemListJsonLd = buildItemListJsonLd({ products: products.docs, siteUrl })

{itemListJsonLd && (
  <script type="application/ld+json"
    dangerouslySetInnerHTML={{ __html: JSON.stringify(itemListJsonLd) }}
  />
)}

BreadcrumbList with nested categories
The BreadcrumbList recursively walks the category parent chain:

Shop → Jewelry → Bracelets → Product Name

const collectParents = (c: any) => {
  if (c.parent && typeof c.parent === 'object') collectParents(c.parent)
  parents.push(c)
}
collectParents(cat)

This requires fetching products at depth: 3 to populate categories and their parents.
AggregateRating — connecting reviews to JSON-LD
Plug in your review data to get Google star ratings in search results:

const productJsonLd = buildProductJsonLd({
  product,
  siteUrl,
  currency: 'EUR',
  averageRating: 4.8,  // from your reviews query
  reviewCount: 42,
})

The plugin only adds aggregateRating when reviewCount > 0 — no empty rating blocks.
Install

npm install payload-plugin-seo-jsonld

import {
  buildProductJsonLd,
  buildBreadcrumbJsonLd,
  buildItemListJsonLd,
  buildWebSiteJsonLd,
  buildOrganizationJsonLd,
} from 'payload-plugin-seo-jsonld'

→ payload-plugin-seo-jsonld on npm

→ GitHub

Part 3 — Enabling Google indexing on new shops
Two things block Google on fresh Payload v3 deployments that aren't obvious:

Default noindex in layout.tsx New Payload projects ship with indexing disabled:

// src/app/(app)/layout.tsx
robots: {
  index: false,  // ← blocks Google
  follow: false,
}

Fix:

sed -i 's/index: false,/index: true,/' src/app/(app)/layout.tsx
sed -i 's/follow: false,/follow: true,/' src/app/(app)/layout.tsx

robots.txt Verify your public/robots.txt allows crawling:

User-agent: *
Allow: /
Sitemap: https://myshop.com/sitemap.xml

Verification:

# Check no noindex header
curl -sI "https://myshop.com/shop" | grep -i "x-robots\|noindex"

# Check single ItemList
curl -s "https://myshop.com/shop" | grep -o '"@type":"ItemList"' | wc -l
# → must return 1

Test structured data: Google Rich Results Test

What I learned
Payload v3 routes are Next.js routes — don't fight the framework, use App Router for parameterized endpoints
Always check migration mode — batch: -1 means Payload manages schema automatically in dev, but won't auto-migrate in prod
Google is strict on JSON-LD — lowPrice not price, one ItemList per page, reviewCount > 0 before adding aggregateRating

Field-level access control is underused — protect sensitive fields at the field level, not just the collection level

Links

Both plugins are officially listed in the Payload Plugin Directory:

payload-plugin-reviews — reviews, moderation & star ratings

payload-plugin-seo-jsonld — complete Schema.org JSON-LD

payload-plugin-reviews — npm
payload-plugin-seo-jsonld — npm
Payload CMS — the framework

Google Rich Results Test

About the author
I'm Camille, a freelance developer specializing in European e-commerce infrastructure. I build and maintain 23 Payload CMS v3 shops deployed across Europe — each country-specific, SEO-optimized, and running in production.
The plugins in this article came directly from real production needs. If something didn't exist, I built it.

🔧 GitHub — github.com/spiritracking-arch
📦 payload-plugin-reviews — npmjs.com/package/payload-plugin-reviews
📦 payload-plugin-seo-jsonld — npmjs.com/package/payload-plugin-seo-jsonld
🌐 ScaleYourShop — https://scaleyourshop.app/
The infrastructure behind these 23 shops