Chroma

Rol

Solo end-to-end ⁠— onderzoek, product, design system, front-end & back-end; gebouwd met Claude Code

Klant

Zelf-geïnitieerd product

Disciplines

Product · Design systems · Tooling · Front-end · Toegankelijkheid

Jaar

2025–2026

Een kleurtool die ik zelf ontwierp en bouwde: paletten uit elke afbeelding, WCAG-contrast en acht exportformaten in één interface. Mijn eigen kleurwerk ging van 3,1 naar 1,0 uur per project (−68%). In 2026 ontwierp ik het opnieuw rond één object: een printer die je palet als kassabon afdrukt

Probleem
Bij SVP was mijn kleurwerk versnipperd over 5–⁠6 losse tools en kostte het 3,1 uur per project
Inzicht
De pijn zat niet in een gebrek aan tools, maar in de naden ertussen ⁠— één doordachte interface, afgestemd op hoe ik echt werk
Oplossing
Ik bouwde Chroma in mijn eentje van A tot Z (onderzoek, design, React/TS frontend, FastAPI backend, DevOps): extractie uit afbeelding én live site, WCAG-matrix, OKLCh-schalen, 8 exportformaten, 25 dagen; in 2026 hertekend als een 3D-printer die ik zelf modelleerde in Cinema 4D en die de analyse als thermische kassabon afdrukt
Resultaat
Mijn eigen kleurwerk terug naar 1,0 uur/project (−68%), €0 hosting ⁠— kleine vroege steekproef

Eén interface voor de volledige kleurenpipeline

Kleurbeslissingen staan aan het begin van zowat elk designproject ⁠— klantpresentaties, merkaudits, product-UI, marketing. Het werk daarachter zat verspreid over 5–⁠6 browsertabbladen: een kleurpipet, een afbeeldingsextractor, een contrastchecker, een exporttool die nooit het formaat opleverde dat developers nodig hadden. Chroma brengt dat samen in één interface.

chroma.ontwrpn.com in 2026 ⁠— het printerontwerp, stand-by en klaar voor een foto

De naden tussen de tools

Een typische opdracht: referenties verzamelen, paletten extraheren, WCAG-contrast testen, tonale schalen van 50 tot 950 opbouwen, aanleveren in het formaat dat de ontvanger ook echt gebruikt. Elke stap zat in een andere tool ⁠— Coolors, Adobe Color, contrastcheckers, Figma-plugins ⁠— en de uitvoer sloot nooit op elkaar aan. Toegankelijkheid kwam telkens te laat aan bod. Uitgangspunt: 3,1 uur kleurkarwei per project, gemeten over 12 afgeronde projecten.

De pijn zit niet in een gebrek aan tools ⁠— maar in de naden ertussen

Eerst valideren, dan bouwen in 25 dagen

Discovery vóór code: een zelfevaluatie van 12 afgeronde projecten (gemiddeld 3,1 uur), gesprekken van twintig minuten met drie mensen die met mijn paletten werken, en gestructureerde walkthroughs van 8 concurrerende tools. Er dook een verborgen kost op ⁠— wie na mij kwam, leidde mijn paletten opnieuw af omdat het aangeleverde formaat niet bij hun tools paste. Daarna bouwde ik solo via afgebakende fasen ⁠— alpha ⁠→ beta ⁠→ productie ⁠— zodat de lancering al bewezen was op echt werk.

Afgedrukt: de bon opent met de scan, daarna het palet volgens werkelijk pixelaandeel

Extraheer ⁠→ balanceer ⁠→ controleer ⁠→ exporteer

Eén webtool voor de volledige kleurenlevenscyclus: extractie uit afbeelding en live site (werkelijke pixelverhoudingen, geen gegenereerde samples), een live WCAG-matrix met kleurenblindheidssimulatie, tonale OKLCh-schalen en acht exportformaten, inclusief W3C design tokens. Gebouwd met Vite + React + TypeScript + Tailwind bovenop FastAPI / Python.

chroma.ontwrpn.com — live-voorbeeld
Live-demo
chroma.ontwrpn.com
Openen

Live ⁠— stop een foto of een site-URL in de printer

Eén oppervlak in plaats van zes betere tools

Elke stap in de kleurworkflow had al een sterkere standalone tool dan wat ik zou bouwen: Coolors voor paletten, Adobe Color voor harmonie, aparte contrastcheckers, Figma-plugins voor toepassing. Het beste van elk samenvoegen was de voor de hand liggende zet. Het was ook precies wat ik verving, want het werk leefde over vijf of zes tabbladen waarvan de output nooit op elkaar aansloot, met een exporter die nooit het formaat leverde dat developers nodig hadden.

De ruil was dus expliciet. Elke functie is afzonderlijk zwakker dan de specialistische tool, in ruil voor één oppervlak dat de hele levenscyclus dekt en waar de output wél met elkaar klopt. Extractie leest echte pixelverhoudingen in plaats van gegenereerde stalen, om dezelfde reden: een palet dat het bronbeeld verkeerd weergeeft, is sneller én nutteloos.

De toets was de overdracht, niet de functielijst: paletten moesten zonder herberekening in decks en code belanden, precies de twee plekken waar de oude vijf-tabbladenworkflow altijd lekte.

Gelanceerd en gemeten

Eerste twee weken op mijn eigen projecten (kleine vroege steekproef, n = 3, tegenover een baseline van 12 projecten): kleurwerktijd 3,1 uur ⁠→ 1,0 uur (−68%), €0 hosting. Eerlijk gezegd ⁠— een kleine vroege steekproef, sindsdien niet opnieuw gemeten. Het enige knelpunt: website-extractie (vs. image upload) duurt 10–⁠12 s zonder zichtbare voortgangsindicator ⁠— een laadstatus staat op de backlog.

Redesign: de printer

In oktober 2026 ontwierp ik het hele product opnieuw rond één metafoor: een printer en zijn kassabon. Je stopt een foto in de bovenste gleuf van een lichte 3D-printer, een rode laser scant hem, en uit de voorste gleuf rolt een lange thermische kassabon met de volledige analyse ⁠— het palet volgens werkelijk pixelaandeel, een donut, harmonie, tinten, de WCAG-contrastmatrix, een simulatie van kleurenzien en een afscheurbon voor de export. De motor eronder is dezelfde; wat veranderde, is hoe het aanvoelt.

De redesign op de live site, in 34 seconden: een foto gaat in de bovenste gleuf, de laser scant hem, de kassabon wordt geprint en een HEX wordt gekopieerd met de COPIED-stempel. Foto van de dahlia: vultilion, CC BY 2.0

Eerst het proces. In Figma verzamelde ik referenties van kassabonnen en thermische printers naast een capture van de live site, en tekende daarna grijze wireframes op een klein wireframe-design system waarvan de Figma-variabelen elk frame laten wisselen tussen een Wireframe- en een Hi-fi-modus. Daarop tekende ik drie concepten: A “Lab” ⁠— warm beton #CFCBC4, een gebroken witte printer, papier #FBFAF7, inkt #141414, een rode scanlaser #FF4D2E, gezet in Archivo en JetBrains Mono; B “Transmission”; en C “Cobalt”. Ik koos A, de rustigste van de drie, zodat de kleur op het scherm van de foto zelf komt.

Scannen: de foto staat in de bovenste gleuf, de laser zakt er stap voor stap overheen

Afdrukken: de bon rolt uit de voorste gleuf

Ik bouwde de 3D-printer in Cinema 4D en renderde hem met Redshift: een afgeronde behuizing met een uitgesneden paneel, pootjes en twee gleuven, belicht met een softbox als key, een fill, een rim en een dome. De pagina ís de render. De DOM-bediening ⁠— bron, kleuren, modus, tolerantie, alfa ⁠— ligt erbovenop, op ankerpunten die op de render zijn opgemeten, zodat ze precies op het paneel van de printer zit en gewone HTML blijft die je met het toetsenbord bereikt.

De printer, gebouwd in Cinema 4D

…en gerenderd in Redshift

De beweging is mechanisch, niet decoratief: de scan schuift in rolstappen, het papier komt er in thermische regelstappen uit, de behuizing zoemt zolang hij werkt en komt tot rust als hij stopt. De details zijn klein en tastbaar ⁠— scanfasen op de led, een HEX-scramble terwijl de waarden binnenkomen, knoppen die indrukken, een gleuf die oplicht als je er iets boven sleept, een COPIED-stempel, een verende afscheurbon voor de export, en kassabonnen die je via een link deelt.

Mobiel: het paneel klapt in tot één rij

Mobiel: dezelfde bon, over de volle breedte

Zelfs de 404 blijft in zijn rol: de printer meldt een papierstoring en drukt een VOID RECEIPT af voor de pagina die ontbreekt. Onder de metafoor is alles nog steeds gebouwd volgens WCAG 2.2 AA, met een minimale tekstgrootte van 14px, een strikte CSP en een printer die op de viewport is afgestemd, zodat het hele toestel op het eerste scherm past.

404 op desktop: een VOID RECEIPT

404 op mobiel

Volgend project
Axonis