CLEW NFC

Why put a chip in a binding?

CLEW Snowboarding, based in Munich, sells its bindings almost entirely through retailers. Good for distribution, bad for customer contact: CLEW does not know who actually wears its products, has no channel for support or warranty claims, and no way to reach customers with a newsletter as long as a retailer sits in between.

The fix sits inside the product itself. Every binding carries an NFC chip, glued to the inside of the highback and covered by the highback pad. Anyone holding the binding just has to tap their phone against it to be one step away from registering. The first product to ship with a chip is the Independence TI Special Edition in TI Black, in sizes S to XL.

How registration works

1. Tap: the customer holds their phone against the binding. No app required, an NFC tap is enough and the phone opens the right page in the browser.
2. Chip lookup: the page reads the token from the URL, checks it against the database and works out whether this particular chip is already registered.
3. Unregistered: the customer lands on a short form, enters their details and the retailer they bought from, and is registered.
4. Registered: every later tap shows a page with their own binding and tiles for support, CLEW and CLEW’s social channels.

What is stored on the chip

The chip is an NTAG213 with 144 bytes of user memory. It carries a single NDEF URL record pointing at the registration page, with a token that only the backend can verify.

Once written, the URL is permanent. That is why no batch was allowed to run before the domain was fixed, and why burning a chip is a final act, not a draft.

Architecture: from the assembly line to the cloud

At the assembly line, a production laptop runs a Python tool that talks to the chip through an Elatec TWN4 reader. Every record is written to a local journal with a forced disk flush first, only then is the chip written, and only after that does the tool sync in the background to Supabase. That order is deliberate: if the internet connection in the factory drops, not a single chip loses its record.

1. Local journal

   forced to disk

2. Write the chip

   NTAG213, final once written

3. Sync to Supabase

   offline, waiting ✓ synced

   in the background

Supabase, hosted in Frankfurt, holds all the data, handles authentication and runs three edge functions that manage tapping, registering and verifying chips. Every access right is enforced through row level security, and the browser itself never holds more than a restricted key. CLEW’s admin dashboard is a static Astro site with React islands, hosted on Vercel, with no server of its own in between.

The dashboard: an inventory register, not a CRM

For the admin dashboard I deliberately went against the usual layout of an admin panel: instead of four equal-sized metric cards sitting above a table, there is one continuous strip of counts across a batch’s states, with a bar underneath showing progress. The reasoning: every row in this dashboard is not a contact in a CRM, it is a physical binding with a serial number. The interface must never look like you are editing a record when, in reality, you are turning a chip into scrap.

That led to a deliberately minimal design in black on white, no rounded corners anywhere, hairlines instead of shadows and cards. CLEW can run it without calling me: managing retailers, maintaining master data such as models, colors and sizes, reviewing, correcting and exporting registrations as CSV, and reading the progress of a running production batch at a glance. Over 300 real retailers are already in the system, each one individually switched on.

What I built

I carried this project from the first architecture decision through to going live at the assembly line, on my own: the Python tool for the production laptop with a CustomTkinter interface, the Supabase database with its edge functions written in Deno, the admin dashboard built with Astro, React and Tailwind CSS on Vercel, and the registration page for the end customer.

Part of it is a local check chain that runs the same steps before every change: Python tests with pytest, 399 of them passing, linting with ruff, tests for the edge functions with Deno, plus two secret scanners that run before every commit. Without that chain I would have had no confidence that a bug in the encoder logic would show up before the assembly line did.

What I learned

Physical systems do not forgive a second attempt. A burned chip ends up in a binding that ships to a customer, and a broken record cannot simply be deleted and recreated the way it can in an ordinary web app. That is what forced the order journal, then chip, then sync, not as a nice idea but as a condition for starting production at all.

The interface has to speak the language of the factory floor. Early message drafts talked about placing a chip down or leaving it in place, a motion that does not exist at the assembly line at all. Only after understanding the real sequence of movements on the line did the tool’s messages become correct, and a test now reads the source code so the old language cannot creep back in.

Status and access

Production started on September 18, 2026. Anyone holding a CLEW binding with a chip can try the system live: clew-nfc.com is the address every tap points to. The admin dashboard is reserved for CLEW and not publicly accessible.

Questions about the project, or a similar undertaking involving NFC, manufacturing and a cloud backend? Write to me at kontakt@bitzer-fabian.de.