DEV Community: Camille Guerineau

Building a white-label crystal bracelet builder with vanilla JS, PHP and zero database

Camille Guerineau — Thu, 15 Oct 2026 13:21:00 +0000

Note from the workshop-lab. The algorithmic tools, configurators and articles presented here explore lithotherapy exclusively through the lens of semiotics, cultural anthropology and generative design. This work belongs to an artistic and symbolic practice rooted in fine craftsmanship. It does not, in any way, constitute medical advice, a diagnosis, or an alternative to conventional, evidence-based therapies.

Loch Ness: Algorithmic System for Archetypal Determination and Variable-Geometry Mineral Synergies | Zenodo

Concept Summary (Abstract) The Loch Ness project redefines the interaction between individual psychology and lithotherapy through a proprietary digital interface. Unlike standardized, fixed-output approaches, this concept rests on two innovative pillars: an original archetypal taxonomy and a variable-geometry mineral sequencing algorithm. 1. The Ontology of the "Noble Monster" The system uses a taxonomy of original archetypes created to reflect the complexity of the human psyche, including its shadow aspects and raw power. The user is not classified according to conventional sociological or demographic criteria, but according to their "wild nature" and their capacity to channel a singular inner force. This classification produces, for each profile, a multidimensional intensity vector rather than a single label. 2. The Variable-Geometry Calculation Algorithm The application processes user data to generate a mineral response whose structure is unique to each profile: Dynamic Sequencing — the number of stones (from 3 to 8 units) is not fixed; it is determined by the algorithm based on the calculated "density" of the archetypal profile. Compensation Synergy — each stone is selected to fulfill a specific functional role (Anchor, Heart, Mind, Shield, Momentum), creating a bespoke vibrational armor rather than an arbitrary assembly. This role-to-stone indirection allows the role nomenclature and the mineral catalog to evolve independently, without recalibrating the entire system with each addition. 3. Algorithmic Pipeline Processing relies on a strictly decoupled three-stage functional pipeline, each stage independently testable: Identity Normalization — identity data (first name(s), last name, date of birth) is transformed into a multidimensional profile vector (intensity, shadow aspect, momentum, stability), with no dependency on rendering or the interface. Density Calculation and Slot Count Resolution — a density function aggregates the profile vector into a scalar score, which is then projected onto the integer interval [3, 8] to dynamically determine the length of the mineral sequence. Role Resolution, then Mineral Selection — for each slot, a functional role is resolved first (Anchor, Heart, Mind, Shield, Momentum), and a stone is then selected from the catalog to fulfill that role in light of the profile vector. 4. Software Architecture The system is implemented as a static single-page web application (SPA), with no dependency on a JavaScript framework, and features the following technical characteristics: Stack — PHP, HTML5, CSS3 (custom properties), vanilla native JavaScript; no dependency on any rendering framework. Generative Rendering Engine — each mineral in the catalog is rendered as a dynamically relying on a static image bank. Dynamic Geometric Layout — the position of each stone on the support (bracelet) is calculated trigonometrically based on its index and the total number of slots resolved by the algorithm (a variable N, not a constant), with automatic bead-size scaling according to the sequence's density. State Management — the composition state is represented as an ordered array of beads, with undo/redo history stacks and targeted re-rendering (rather than a full re-render) on each mutation, to preserve smoothness on mobile. Progressive Web App — an installation manifest (icons, theme color, standalone mode) and a Service Worker providing static resource caching and partial offline resilience. Structured Data — Schema.org markup (SoftwareApplication, FAQPage) for enriched indexing, in addition to visible HTML content. Full architecture documentation (flow diagrams, justified technical choices) along with simplified code examples for educational purposes are published separately. The actual normalization tables, the density function, the role-resolution thresholds, and the complete mineral catalog are not published and constitute the proprietary core of the system. Purpose of This Filing This document records the intellectual property of the algorithmic logic, the archetype nomenclature, and the mineral selection methodology associated with the Loch Ness brand. It protects the invention of a personalization system in which technology becomes the bridge between an individual's deep identity and the talismanic object. Live application: healing crystal bracelets configurator with lithotherapy score

zenodo.org

I have been making jewellery in Paris since 2013, and I write code. For a long time those were two separate jobs. This post is about the project where they finally met: a bracelet builder where people compose a bracelet bead by bead from photos of real stones, get a "composition score", and send the design to a shop that strings it by hand.

It started as a single page for my own workshop. It is now a white-label tool that other shops embed on their sites, plus a small ecosystem of static pages around it. Here is how it works under the hood, and the constraints that shaped it.

The constraints

Shared PHP hosting, deployed over FTP. No Node server, no containers, no database server.
One person maintains everything, so every moving part has to justify itself.
Three languages (English, French, Spanish) from day one.
Real stones. Every bead is a photo of an actual bead from my workshop, cut out by hand. 58 references today.

Those constraints pushed me towards a design I would recommend for small projects: a static front end, a thin PHP layer, and JSON files as the database.

Architecture at a glance

/pwa/{en,fr,es}/index.html      ← the builder: one self-contained page per language (vanilla JS, PWA)
/pwa/{en,fr,es}/configs/*.json  ← white-label settings, one file per shop
/pwa/api/catalog.json           ← stones, properties, scoring constants (exported from the front end)
/pwa/api/publish.php            ← receives a finished bracelet, recomputes everything, writes static pages
/pwa/api/lib/Litho.php          ← the scoring engine, ported from JS to PHP
/pwa/api/data/*.json            ← index of published creations, rate limits, settings
/creations/  /bracelets/  /pulseras/   ← generated static pages (EN / FR / ES)

No framework, no build step for the builder itself. The page loads, fetches its config, and runs.

1. The builder: one page, vanilla JS

The bracelet is a ring of slots. Its size comes from two choices: the wrist circumference (14 to 23 cm) and the bead diameter (6, 8 or 10 mm, depending on the wrist size). The number of beads is simply what fits around the wrist:

const WRIST_OPTIONS = { 14: [6, 8], 16: [8, 10], 19: [8, 10], 21: [10], 23: [10] }; // cm → bead sizes (mm)
function beadCountFor(wristCm, diamMm) { return Math.round((wristCm * 10) / diamMm); }

Each slot is absolutely positioned on a circle, and the whole ring sits in a rotating container. A few details that made a big difference in feel:

Fly-in animation: when you tap a stone card, a clone of its image flies to the next free slot (Web Animations API), then the real bead "lands" with a short scale-and-brightness keyframe.
Undo: removing a bead or emptying the bracelet shows a toast with an Undo button for 5 seconds (and Ctrl+Z on desktop). The state is just an array of bead objects, so undo is a copy.
Two layouts, one DOM. Below 700 px wide the original mobile layout is untouched; above, a html.wide class switches to a two-column layout. I verify the mobile layout with pixel diffs (Playwright screenshots before/after at 375, 390 and 430 px) every time I touch the desktop CSS.

// the layout switch, run before first paint
const wide = innerWidth >= 700 && innerHeight >= 560;
document.documentElement.classList.toggle('wide', wide);

2. The composition score

When the bracelet is complete, the builder computes a score out of 100 and names the result, from "Emerging Amulet" to "Alchemical Bracelet". Each stone carries symbolic attributes taken from lithotherapy traditions: a chakra position (1 to 7), an element, a "vibration level", a polarity (yin, yang, neutral) and a dominant property (grounding, soothing, protective…).

The interesting part is that position matters. In the energetic mode, the score looks at every pair of beads and asks how well their attributes go together, but a bead's neighbours count more than a bead on the opposite side of the ring. The distance is circular:

// N beads on a ring; rho = 0.5 in the current catalog
const delta = (i, j) => { const d = Math.abs(i - j); return Math.min(d, N - d); };
const weight = (i, j) => Math.pow(rho, delta(i, j) - 1);   // neighbours: 1, then 0.5, 0.25…

function pairScore(phi) {                 // phi(a, b) → compatibility, or null if unknown
  let num = 0, den = 0;
  for (let i = 0; i < N; i++) for (let j = i + 1; j < N; j++) {
    const v = phi(S[i], S[j]); if (v == null) continue;
    const w = weight(i, j); num += w * v; den += w;
  }
  return den ? num / den : null;
}

Four phi functions (chakra distance, element pairs, vibration gap, property pairs) produce four weighted averages. Polarity balance and a few small bonuses (an odd number of beads, a chakra sequence that rises around the ring) complete the total, clamped to 0–100. The panel shows the five sub-scores as bars, the chakras and elements represented, and practical care notes such as stones that should not go in water.

The aesthetic mode is a different model: it rewards coverage and variety (how many chakras and elements are represented, how diverse and evenly spread the properties are, how many different stones are used) plus bonuses for known combinations.

To be clear about what this is: a generative design system built on symbolic data, in the same spirit as a colour-harmony tool. It encodes traditions; it does not measure anything about the person wearing the bracelet.

3. Never trust the browser: recompute on the server

Finished bracelets can be published as pages in a public gallery. The tempting shortcut would be to let the browser send the score and the texts. Instead, publish.php accepts exactly three things: the list of bead IDs, the display mode, and a PNG of the share card.

// publish.php (excerpt)
foreach ($ids as $id) {
    if (!is_int($id) && !(is_string($id) && ctype_digit($id))) fail('bad_ids');
    if (!$L->hasBead((int)$id)) fail('unknown_bead');
}
$contents = $L->contents($clean);        // full score + texts, recomputed in PHP

The PNG is decoded and re-encoded with GD, which strips anything hidden in the file. Every word on the generated page comes from catalog.json, never from the request.

That meant porting the scoring engine from JavaScript to PHP, and keeping both in sync. The subtle part was the deterministic text variation: each page picks phrasing variants with a seeded hash, and the seed must be identical in both languages. JavaScript does 32-bit multiplication with Math.imul on UTF-16 code units; PHP has neither, so the port re-implements both:

// 32-bit unsigned multiply, matching Math.imul(a, b) >>> 0
protected static function imulU(int $a, int $b): int {
    $a &= 0xFFFFFFFF; $b &= 0xFFFFFFFF;
    $lo = ($a & 0xFFFF) * $b;
    $hi = (($a >> 16) * $b) & 0xFFFF;
    return ($lo + ($hi << 16)) & 0xFFFFFFFF;
}
// FNV-1a over UTF-16 code units, like s.charCodeAt(i) in JS
foreach (self::utf16Units($s) as $u) { $h ^= $u; $h = self::imulU($h, 16777619); }

Same bracelet in, same page out, in both runtimes: that is what makes the port checkable.

4. Static pages that regenerate themselves

Each published bracelet becomes a static HTML page in three languages, plus pages for each stone and a sitemap. There is no database query at read time: the web server just serves files.

A few rules keep this from turning into a spam factory:

Deduplication: the same set of stones (in any proportions) maps to the same page, so a visitor who tweaks one bead does not create a near-duplicate.
Indexing rules: only bracelets above a score threshold and with enough different stones are proposed to search engines; the rest stay noindex.
Moderation: new creations are published in a pending state. The visitor's share link works immediately, but the page stays out of the gallery and the sitemap until it is reviewed in a small admin.
Rate limits per visitor and per day, stored in a JSON file behind an exclusive flock.

When a setting or a stone description changes, one call regenerates every page from the index. Writes are atomic (write to a temp file, then rename), so a visitor never sees half a page.

5. White label without a multi-tenant backend

Shops do not get a copy of the code. They get a JSON file:

{
  "nom": "Maison Opale",
  "logo": "https://example.com/logo.png",
  "couleurs": { "accent": "#6d3f7d", "btn-color": "#6d3f7d" },
  "masquer": [12, 31],
  "prix": { "4": 1.9 },
  "cadre": { "epaisseur": 1, "arrondi": 16 }
}

The builder reads ?client=…, fetches configs/<client>.json, and applies it: colours become CSS custom properties (shades are derived from the main colour in JS), hidden stones are removed from the catalogue, prices are overridden. A client area lets each shop edit its file through a form, validated server-side, with a backup of the previous version.

Embedding works three ways: a direct link, an <iframe>, or a one-line script that injects a floating button. The button lives in a Shadow DOM so the host site's CSS cannot break it, and the iframe is only created on first click, so the shop's page stays fast. When the builder detects it runs inside an iframe (window.self !== window.top), it draws a discreet, configurable frame so it does not look like a pasted screenshot.

6. The holistic layer: Stone of the Day

The same catalogue feeds a sister app, Stone of the Day, which suggests a stone by intention, by numerology "life path" number, by moon phase or by zodiac season. The moon phases are computed in PHP with Jean Meeus's algorithm from Astronomical Algorithms (chapter 49), accurate to a few minutes, so the pages stay correct without any external API.

Because everything reads from one catalogue, improving a stone's description updates the builder, its score texts, the stone pages and the Stone of the Day at once. For a solo maintainer, that single source of truth is the whole point.

What I would do the same way again

JSON files instead of a database for a few thousand records with rare writes. flock and atomic renames cover concurrency.
Server-side recomputation of anything that gets published. The browser only sends identifiers.
Pixel-diff tests to protect a layout that already works, before redesigning another one.

What I would do differently

Prices are hard-coded in euros; a currency setting per shop should have existed from the start.
One HTML file per language means fixes have to be applied three times. A small build step generating the three files from one template would pay for itself.

Try it

The builder: lochness-paris.com/pwa/en/
Stone of the Day: lochness-paris.com/pwa/pierre-du-jour/en/

I'm happy to answer questions about the scoring model, the JS-to-PHP port or running a "static site that writes itself" on shared hosting.

Note from the workshop-lab: the algorithmic tools, configurators and articles presented here explore lithotherapy exclusively through the lens of semiotics, cultural anthropology and generative design. This work belongs to an artistic and symbolic practice rooted in fine craftsmanship. It does not, in any way, constitute medical advice, a diagnosis, or an alternative to conventional, evidence-based therapies.

It's a philosophical question! For my part, I contribute to implementing this distinction for artists solely through my label VERUMANO. It's a technically sophisticated open-source project (GitHub and npm repository) that allows for reliable human.

Camille Guerineau — Wed, 14 Oct 2026 17:26:59 +0000

Camille Guerineau

Oct 14

I built a verifiable "human-made" badge without collecting a single file

#webdev #ai #opensource #javascript

6 min read

I built a verifiable "human-made" badge without collecting a single file

Camille Guerineau — Wed, 14 Oct 2026 14:31:02 +0000

I spent ten years as a jewelry maker before going back to full-stack development, so I care about this one personally. I wanted a badge that means something: someone actually looked at how the work was made, the badge can be checked by anyone in one click, and it can be revoked if it turns out to be false.

Verumano Human Origin (NO AI) Specification v0.3 | Zenodo

The Verumano Specification defines how the Verumano label (formerly Human Origin) certifies human-made creative work through a review of the creative process, not through AI detection. It specifies: Creator identifiers (VM-YYYY-NNNN; legacy HO- IDs remain valid) A closed set of statuses: reviewed, self-declared, revoked, demo Review requirements: live walkthrough or screen recording with a one-time code, evidence by discipline (writing, illustration, photography, music, video) Public verification pages and their required fields Dynamic SVG badges, seals and watermarks, rendered by the server so that revocation shows everywhere within one hour Work fingerprints: SHA-256 computed on the user's device; files are never uploaded A read-only public verification API (CORS, no key, rate-limited without storing IP addresses) Revocation, domain blocking, privacy and retention rules Security limits and conformance rules for third-party platforms The label does not claim to prove that no AI was used. It certifies that a human creative process was shown and examined. What's new in v0.3: the label is renamed Verumano. New creator IDs use the VM prefix; existing HO IDs stay valid and are never reassigned. The reference implementation moves to lochness-paris.com/verumano and the former subdomain redirects permanently. Statuses, badges and API are unchanged. Links: Reference implementation: https://lochness-paris.com/verumano/ Specification (online): https://lochness-paris.com/verumano/spec/ Verification API: https://lochness-paris.com/verumano/api/ Comparison with other labels: https://lochness-paris.com/verumano/compare/ Schemas, examples and client library: github.com/spiritracking-arch/human-origin-label-nope-ai Companion concept paper: doi:10.5281/zenodo.23072755 Text licensed under CC BY-NC 4.0. Code samples under MIT. Creative Commons Attribution-NonCommercial 4.0 International Public License (CC BY-NC 4.0) Copyright (c) 2026 Camille Guerineau Applies to the documentation, specifications (spec/), and the Creator Charter (charter/). You are free to: - Share: Copy and redistribute the material in any medium or format. - Adapt: Remix, transform, and build upon the material. Under the following terms: 1. Attribution: You must give appropriate credit, provide a link to the license, and indicate if changes were made. 2. Non-Commercial: You may not use the material for commercial purposes. Any commercial exploitation, corporate internal use, or monetization requires a separate written commercial agreement from the copyright holder. Full legal code is available at: https://creativecommons.org Trademarks & Certification Notice: The name "VERUMANO", the official badges, and the logo are strictly excluded from this public license. Implementing or referencing this specification does not grant any right to issue Human Origin badges, use the logo, or present a commercial service under the "Human Origin" brand identity.

zenodo.org

That project is Verumano. Here is how it works under the hood, and the trade-offs I made.

The constraint that shaped everything: no files

The obvious design is "upload your work, we analyse it". I refused that for three reasons:

Creators don't want to hand their unpublished work to yet another platform.
Storing files means storage, security and GDPR headaches.
AI detectors on the final file are unreliable. They produce false positives on real human work.

So Verumano reviews the process (drafts, sketches, timelapses, version history, raw files) shown by the creator through links, and it never keeps the work itself. What it stores is a public record: who, which discipline, which status, since when.

Architecture: boring on purpose

PHP 8 + Apache, shared hosting
The registry is a JSON file, written with flock() to avoid concurrent write corruption
The data folder is outside the web root logic and protected with Require all denied
No framework, no database, no build step

For a registry with hundreds (not millions) of entries, this is fast, cheap and easy to back up. A database can come later if it is ever needed.

Badges are rendered, not downloaded

The badge a creator embeds is not a static image. It is an SVG generated on every request from the registry:

<a href="https://lochness-paris.com/verumano/verify/VM-2026-0001">
  <img src="https://lochness-paris.com/verumano/badges/badge-illustration-reviewed-light-0001.svg"
       alt="Verumano: human-made illustration, process reviewed" width="380" height="112">
</a>

Because the server draws it, the status is always current:

Status	Colour	Meaning
Reviewed	green `#1E6B45`	the creation process was examined
Declared	orange `#FF8C1A`	the creator declares it, not reviewed
Revoked	red `#A3261B`	no longer valid, shown crossed out

A few details that matter:

Status is never colour-only. Each state has its own text and icon, for colour-blind readers.
Cache of 1 hour (Cache-Control: public, max-age=3600). A revocation shows everywhere within the hour, without hammering the server.
An unlisted discipline returns 404. You can't request badge-music-reviewed-light-0001.svg if you were reviewed for illustration only.
The badge links to the public verification page, which is the real proof. The image is just the door.

Detecting copied badges (and why it's only partial)

When a badge is loaded, the server can read the Referer header and compare it with the domains declared by the creator. If a badge shows up on a site that isn't on the list, it gets logged for review.

This is deliberately not used to block automatically. Modern browsers send strict-origin-when-cross-origin by default, many sites send no-referrer, and privacy extensions strip it. So the rule is simple:

No information = no sanction.

The referer is a signal for a human to look at, never a verdict.

Certifying the exact file, without uploading it

Creators can attach a fingerprint of a specific file to their record: a SHA-256 hash, computed in the browser. The file never leaves the computer, only 64 hex characters do.

crypto.subtle.digest() needs the whole file in memory, which is a problem for a 2 GB video. So the file is read in 4 MB chunks and fed to an incremental SHA-256. Simplified:

async function hashFile(file, onProgress) {
  const CHUNK = 4 * 1024 * 1024;           // 4 MB
  const hasher = createSha256();           // incremental SHA-256
  for (let offset = 0; offset < file.size; offset += CHUNK) {
    const buf = await file.slice(offset, offset + CHUNK).arrayBuffer();
    hasher.update(new Uint8Array(buf));
    onProgress?.(Math.min(1, (offset + CHUNK) / file.size));
  }
  return hasher.hex();                     // "9f2c…"
}

Anyone can later drop the same file on the verify page and get "this exact file is registered" or "not found".

The honest limit: a hash identifies bytes, not an image. Re-export, crop or recompress the file, and the hash changes. That's fine for originals, masters and deliverables. It's not a tool to track copies across social networks.

A read-only public API

Platforms, contests and juries need to check entries in bulk, so there is a small read-only API:

# Check a creator record
curl https://lochness-paris.com/verumano/api/v1/creators/VM-2026-0001

# Check whether an exact file is registered
curl "https://lochness-paris.com/verumano/api/v1/works?sha256=9f2c...e41a"

{
  "api_version": "1",
  "creator": {
    "id": "VM-2026-0001",
    "status": "reviewed",
    "demo": true,
    "name": "Nora Lindqvist (demo)",
    "disciplines": ["illustration"],
    "scope": "Example: a series of ink and watercolor illustrations",
    "reviewed_on": "2026-09-15",
    "method": "Live video walkthrough",
    "url": "https://lochness-paris.com/verumano/verify/VM-2026-0001"
  }
}

(Trimmed: the real response also lists the evidence examined, the certified works and the charter version.)

Design choices:

CORS open, GET only (405 otherwise), clear 400 / 404 / 429 errors
Rate limit of 60 requests per minute, keyed on a salted IP hash whose salt rotates daily. No raw IP is stored
5-minute cache on responses
No personal data beyond what is already public on the verification page

On top of it there is a small jury tool: paste a CSV of entries (name, record number, social link), and it checks each one against the registry, including whether the social profile actually matches the one declared. A first version accepted any Instagram URL. Comparing the full profile path fixed that.

Try it in 30 seconds: the npm package

Calling the API by hand is fine, but nobody wants to re-implement chunked hashing. So there is a small client on npm, with zero dependencies, for browsers and Node.js 18+:

npm i verumano

import { getCreator, checkFile } from 'verumano';

// Is this creator registered, and what is their status?
const record = await getCreator('VM-2026-0001');
console.log(record?.creator.status); // "reviewed"

// Is this exact file certified? Hashed locally, never uploaded.
const result = await checkFile(file); // a File in the browser, a path in Node
console.log(result.matches.length ? result.matches[0].status : 'not registered');

And if you just want to show a live badge on a page, there is a web component, no build step needed:

<script type="module" src="https://cdn.jsdelivr.net/npm/verumano@0.1/badge.js"></script>
<verumano-badge creator="VM-2026-0001" discipline="illustration"></verumano-badge>

The badge image is still rendered by the server at display time, so a revoked badge turns red everywhere within the hour. The package is published from GitHub Actions with npm trusted publishing and provenance, so you can check exactly which commit it was built from.

Want to try it without installing anything? Here is a live demo, running the package against the real API:

stackblitz.com

(Open the demo in StackBlitz if the embed does not load.)

An open specification

A label only becomes a standard if others can read the rules and implement them. So the rules are public:

Specification (RFC 2119 style, v0.3): https://lochness-paris.com/verumano/spec/
Schemas, examples and the npm client on GitHub: https://github.com/spiritracking-arch/human-origin-label-nope-ai
npm package: https://www.npmjs.com/package/verumano
Specification on Zenodo: https://doi.org/10.5281/zenodo.23072758
Concept paper: https://doi.org/10.5281/zenodo.23072755

Docs are CC BY 4.0, code is MIT. The server code itself isn't open yet. The review process is still in a pilot phase, and I'd rather stabilise it before inviting forks of the registry.

What it does not claim

I think this part matters as much as the code:

It is not proof that no AI was used. Nothing can prove that. It certifies that a human creation process was shown and examined.
A process can be staged. The review raises the cost of lying, it doesn't make lying impossible. That's also why revocation exists.
During the pilot, reviews are done by one person (me). More reviewers will come with the specification.

Try it

Website: https://lochness-paris.com/verumano/
Install the client: npm i verumano
Verify a demo record: https://lochness-paris.com/verumano/verify/VM-2026-0001
Fingerprint a file in your browser: https://lochness-paris.com/verumano/fingerprint/
API docs: https://lochness-paris.com/verumano/api/
How it compares to other labels (sourced): https://lochness-paris.com/verumano/compare/
Apply as a creator: https://lochness-paris.com/verumano/apply/

If you find it useful, a ⭐ on the GitHub repo helps a lot.

I'd really like feedback from developers here, especially on two points: how would you make badge copying harder without tracking people, and what would make you trust (or ignore) a label like this on a portfolio?

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

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

Note from the workshop-lab. The algorithmic tools, configurators and articles presented here explore lithotherapy exclusively through the lens of semiotics, cultural anthropology and generative design. This work belongs to an artistic and symbolic practice rooted in fine craftsmanship. It does not, in any way, constitute medical advice, a diagnosis, or an alternative to conventional, evidence-based therapies.

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: Algorithmic System for Archetypal Determination and Variable-Geometry Mineral Synergies | Zenodo

zenodo.org

The result is Loch Ness™, the engine behind Loch Ness Paris' crystal 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 php, 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.

Update, October 2026: both plugins are now at v1.0.2. They are published from GitHub Actions with npm trusted publishing (no tokens) and provenance, and their npm pages now link back to the source. If one of them saves you time, a ⭐ on GitHub is the best way to help other Payload devs find it: reviews · seo-jsonld.

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 and 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: a relationship to products, a rating (1-5), a status select (pending/approved/rejected) and 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
→ Source on GitHub (⭐ welcome)

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 break 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, so there are no empty rating blocks. The two plugins are designed to work together: reviews collects and moderates the ratings, seo-jsonld turns them into stars in Google.

Install

npm install payload-plugin-seo-jsonld

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

→ payload-plugin-seo-jsonld on npm
→ Source on GitHub (⭐ welcome)

Part 3: Enabling Google indexing on new shops

Two things block Google on fresh Payload v3 deployments that aren't obvious.

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

2. 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 with the Google Rich Results Test.

What I learned

Payload v3 routes are Next.js routes. Don't fight the framework: use the App Router for parameterized endpoints.
Always check migration mode. batch: -1 means Payload manages the 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.

About the author

I'm Camille Guerineau, a freelance developer specializing in European e-commerce infrastructure. Before that, I spent ten years as a jewelry maker and founder of Loch Ness Paris, so I came to e-commerce from the shop side first. Today 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: npm
📦 payload-plugin-seo-jsonld: npm
🌐 ScaleYourShop: scaleyourshop.app, the infrastructure behind these 23 shops
✅ Verumano: a verifiable "human-made" label, my other open project, with its own npm client (verumano)

Questions, bugs or a feature you need? Open an issue on GitHub or leave a comment below. 👇

DEV Community: Camille Guerineau

Building a white-label crystal bracelet builder with vanilla JS, PHP and zero database

Loch Ness: Algorithmic System for Archetypal Determination and Variable-Geometry Mineral Synergies | Zenodo

The constraints

Architecture at a glance

1. The builder: one page, vanilla JS

2. The composition score

3. Never trust the browser: recompute on the server

4. Static pages that regenerate themselves

5. White label without a multi-tenant backend

6. The holistic layer: Stone of the Day

What I would do the same way again

What I would do differently

Try it

It's a philosophical question! For my part, I contribute to implementing this distinction for artists solely through my label VERUMANO. It's a technically sophisticated open-source project (GitHub and npm repository) that allows for reliable human.

I built a verifiable "human-made" badge without collecting a single file

I built a verifiable "human-made" badge without collecting a single file

Verumano Human Origin (NO AI) Specification v0.3 | Zenodo

The constraint that shaped everything: no files

Architecture: boring on purpose

Badges are rendered, not downloaded

Detecting copied badges (and why it's only partial)

Certifying the exact file, without uploading it

A read-only public API

Try it in 30 seconds: the npm package

An open specification

What it does not claim

Try it

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

Loch Ness: Algorithmic System for Archetypal Determination and Variable-Geometry Mineral Synergies | Zenodo

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

Background

Part 1: The Reviews Plugin

What didn't exist

Building the collection

The relationship bug: "108 0" instead of 108

Custom endpoints don't work for parameterized routes in v3

The database table doesn't auto-create

Install

Part 2: The JSON-LD Plugin

What didn't exist

Bug 1: price vs lowPrice

Bug 2: prices stored in cents

Bug 3: ItemList duplicates break Google validation

BreadcrumbList with nested categories

AggregateRating: connecting reviews to JSON-LD

Install

Part 3: Enabling Google indexing on new shops

1. Default noindex in layout.tsx

2. robots.txt

What I learned

Links

About the author

The relationship bug: `"108 0"` instead of `108`

Bug 1: `price` vs `lowPrice`

1. Default `noindex` in layout.tsx