CLEW NFC

Warum ein Chip in der Bindung?

CLEW Snowboarding aus München verkauft seine Bindungen fast ausschließlich über Händler. Das ist gut für den Vertrieb und schlecht für den Kontakt zum Kunden: CLEW weiß nicht, wer die eigenen Produkte trägt, hat keinen Weg für Support oder Garantie und keinen Kanal für den Newsletter, solange der Händler dazwischensteht.

Die Lösung liegt im Produkt selbst. In jeder Bindung sitzt ein NFC-Chip, verklebt auf der Innenseite des Highbacks, darüber das Highback-Pad. Wer die Bindung in der Hand hält, muss das Handy nur kurz dranhalten und ist einen Schritt von der Registrierung entfernt. Erstes Produkt mit Chip: die Independence TI Special Edition in TI Black, in den Größen S bis XL.

So funktioniert die Registrierung

1. Scannen: Der Kunde hält das Handy an die Bindung. Kein App-Download nötig, NFC-Scan reicht, das Handy öffnet die passende Seite im Browser.
2. Chip erkennen: Die Seite liest den Token aus der URL, prüft ihn gegen die Datenbank und stellt fest, ob dieser Chip schon registriert ist.
3. Unregistriert: Der Kunde landet auf einem kurzen Formular, trägt seine Daten und den Händler ein, bei dem er gekauft hat, und ist registriert.
4. Registriert: Jeder weitere Scan zeigt eine Seite mit der eigenen Bindung und Kacheln zu Support, CLEW und den sozialen Kanälen von CLEW.

Was auf dem Chip steht

Der Chip ist ein NTAG213 mit 144 Byte Nutzspeicher. Darauf liegt ein einziger NDEF-URL-Eintrag, der auf die Registrierungsseite zeigt und einen Token trägt, den nur das Backend prüfen kann.

Die URL ist unwiderruflich, sobald sie gebrannt ist. Deshalb durfte in diesem Projekt keine Charge laufen, bevor die Domain feststand, und deshalb ist jeder gebrannte Chip ein endgültiger Vorgang, kein Entwurf.

Architektur: vom Förderband in die Cloud

Am Förderband steht ein Produktionslaptop mit einem Python-Werkzeug, das über ein Elatec TWN4 Lesegerät mit dem Chip spricht. Jeder Datensatz landet zuerst in einem lokalen Journal mit erzwungenem Schreiben auf die Platte, danach erst wird der Chip beschrieben, danach synchronisiert das Werkzeug im Hintergrund nach Supabase. Diese Reihenfolge ist Absicht: Geht die Internetverbindung in der Halle aus, verliert kein einziger Chip seinen Datensatz.

1. Lokales Journal

   erzwungen auf die Platte

2. Chip beschreiben

   NTAG213, endgültig nach dem Brennen

3. Sync nach Supabase

   offline, wartet ✓ synchronisiert

   im Hintergrund

Supabase in Frankfurt trägt alle Daten, die Authentifizierung und drei Edge Functions, die das Scannen, das Registrieren und die Prüfung der Chips übernehmen. Zugriffsrechte hängen vollständig an Row Level Security, der Browser selbst hält nie mehr als einen eingeschränkten Schlüssel. Das Admin-Dashboard für CLEW ist eine statische Astro-Seite mit React-Inseln, gehostet auf Vercel, ohne eigenen Server dazwischen.

Das Dashboard: ein Bestandsregister, kein CRM

Für das Admin-Dashboard habe ich bewusst gegen die übliche Anordnung eines Verwaltungswerkzeugs entschieden: keine vier gleich großen Kennzahlkarten über einer Tabelle, sondern ein durchgehender Streifen aus Mengen über den Zuständen einer Charge, darunter ein Balken, der den Fortschritt zeigt. Der Grund: Jede Zeile im Dashboard ist kein Kontakt in einem CRM, sondern eine physische Bindung mit einer Seriennummer. Die Oberfläche darf nie den Eindruck erwecken, man bearbeite einen Datensatz, wenn man in Wahrheit einen Chip unbrauchbar macht.

Daraus folgt ein eigenes, minimalistisches Design in Schwarz auf Weiß, ohne abgerundete Ecken, mit Haarlinien statt Schatten und Karten. CLEW kann darin selbst arbeiten, ohne mich anzurufen: Händler pflegen, Stammdaten wie Modelle, Farben und Größen anlegen, Registrierungen prüfen, korrigieren und als CSV exportieren, und den Fortschritt der laufenden Produktion auf einen Blick erkennen. Über 300 echte Händler liegen bereits im System, jeder einzeln aktivierbar.

Was ich gebaut habe

Ich habe dieses Projekt von der ersten Architekturentscheidung bis zur Inbetriebnahme am Förderband allein umgesetzt: das Python-Werkzeug für den Produktionslaptop mit CustomTkinter-Oberfläche, die Supabase-Datenbank samt Edge Functions in Deno, das Admin-Dashboard mit Astro, React und Tailwind CSS auf Vercel, und die Registrierungsseite für den Endkunden.

Dazu gehört eine lokale Prüfkette, die vor jeder Änderung dieselben Schritte fährt: Python-Tests mit pytest, darunter 399 grüne Fälle, Lint mit ruff, Tests für die Edge Functions mit Deno, dazu zwei Geheimnis-Wächter, die vor jedem Commit greifen. Ohne diese Kette hätte ich keine Sicherheit gehabt, dass ein Fehler in der Encoder-Logik erst am Förderband auffällt.

Was ich gelernt habe

Physische Systeme verzeihen keinen zweiten Versuch. Ein gebrannter Chip sitzt in einer ausgelieferten Bindung, ein fehlerhafter Datensatz lässt sich nicht einfach löschen und neu anlegen wie in einer normalen Webanwendung. Das hat die Reihenfolge Journal vor Chip vor Sync erzwungen, nicht als Idee, sondern als Bedingung für den Start der Produktion.

Die Sprache der Oberfläche muss die Sprache der Halle sein. Frühe Textentwürfe sprachen davon, einen Chip aufzulegen oder liegen zu lassen, eine Bewegung, die es am Förderband gar nicht gibt. Erst nachdem ich den tatsächlichen Ablauf an der Linie verstanden hatte, wurden die Meldungen im Werkzeug richtig, und ein Test liest seitdem den Quelltext, damit die alte Sprache nicht zurückkommt.

Stand und Zugang

Die Produktion ist am 18. September 2026 gestartet. Wer eine CLEW-Bindung mit Chip in der Hand hält, kann das System live testen: clew-nfc.com ist die Adresse, auf die jeder Scan zeigt. Das Admin-Dashboard ist für CLEW reserviert und nicht öffentlich zugänglich.

Fragen zum Projekt oder ein ähnliches Vorhaben mit NFC, Fertigung und Cloud-Anbindung? Schreib mir an kontakt@bitzer-fabian.de.