HueKit

Er is een soort zoekopdracht die iedereen die met kleur werkt vroeg of laat doet: je hebt een hexcode en je hebt hem in een ander formaat nodig. Alleen al 'hex to rgb' staat in ons keyword-onderzoek op 49.000 zoekopdrachten per maand met een keyword difficulty van 3. Dat is een vraag die niet weggaat, en die op zich helemaal niet moeilijk te beantwoorden is. Toch is het aanbod in die niche opvallend zwak: pagina's die traag laden, waar je het antwoord moet zoeken tussen alles wat er omheen staat, en die één omzetting geven terwijl je er meestal meer nodig hebt.

Want wie een hexcode omzet naar RGB, wil daarna vaak ook de HSL-waarde voor een CSS-variabele, de CMYK-waarde voor drukwerk, een paar tinten lichter en donkerder, en het antwoord op de vraag of er zwarte of witte tekst overheen kan. Dat zijn vier of vijf verschillende sites, of vier of vijf keer dezelfde site opnieuw laden. De kans lag dus niet in een nieuwe converter, maar in het volledige antwoord in één keer, op één scherm, zonder wachten.

HueKit is vanuit die gedachte opgezet, met als tagline 'The color lab for designers and developers'. Naast de conversies zitten er de dingen in die dezelfde doelgroep in dezelfde week nodig heeft: een box-shadow-generator, een gradient-generator, een glassmorphism-generator, een WCAG-contrastchecker en een palet-extractor voor afbeeldingen. Veertien conversieroutes en vijf generatoren en checkers, allemaal met dezelfde kleurwiskunde eronder.

Bij een site over kleur zit er een ontwerpprobleem in het onderwerp zelf. Als het merk zelf hard kleurt, vecht het met de kleur die de bezoeker net heeft ingevoerd, en dan kun je niet meer zien wat je aan het beoordelen bent. We hebben daarom een eigen designsysteem gemaakt dat we Chromatic Lab noemen: een wit canvas, inktzwarte tekst, licht koel getinte neutralen, en één spectrumgradiënt (cyaan naar blauw naar magenta naar amber) die alleen op de accenten mag verschijnen. Zo blijft de kleur van de gebruiker het felste ding op de pagina.

Daarnaast zijn de swatches bewust groot en tastbaar gemaakt. Een kleurvlak van een paar pixels is nutteloos om te beoordelen; een groot vlak waar je op kunt klikken om de waarde te kopiëren, is meteen bruikbaar. Space Grotesk voor de koppen geeft het geheel iets van een instrument, Inter voor de lopende tekst houdt de uitleg leesbaar, en waarden staan consequent in monospace zodat een hexcode er ook uitziet als iets dat je kopieert.

Dit is geen template en geen CSS-framework. Het hele merk staat in één stylesheet, opgebouwd uit CSS custom properties voor canvas, inkt, hairlines, de spectrumaccenten, de signature gradient, de spacing-schaal en de radii, met daarbovenop de klassen die de componenten vormen. Het is ook het enige CSS-bestand in de repo, dus een aanpassing aan het merk gebeurt op één plek en werkt door op de hele site. Verder brengt de site alleen de stylesheets mee die Next zelf voor de twee lettertypen genereert; die fonts worden tijdens de build opgehaald en meegeleverd, zodat de browser van de bezoeker er geen externe fontdienst voor hoeft aan te spreken. Reduced motion wordt gerespecteerd: wie animaties heeft uitgezet, krijgt ze niet.

De hele site is Next.js 16 met de App Router, React 19 en TypeScript in strict mode, en verder niets. In de package.json staan drie runtime-dependencies: next, react en react-dom. Geen kleurbibliotheek, geen UI-kit, geen analytics-SDK die zich in de bundel nestelt. De conversies, de WCAG 2.1 relatieve luminantie en contrastratio, de tinten, de schaduwen en de harmonieën komen uit één pure module die we zelf hebben geschreven. Die module importeert niets, en is daardoor even bruikbaar tijdens de build als in de browser: dezelfde functie die een kleurpagina vooraf uitrekent, rekent live mee als je in de converter een slider versleept.

Die keuze heeft een direct gevolg voor de bezoeker. Er is geen eigen backend en geen database, en in de repo staan geen route handlers en geen server actions, dus er is tijdens het gebruik van de tools ook niets om iets naartoe te sturen. Als je een hexcode intikt, gaat die code nergens heen. De palet-extractor is daar het duidelijkste voorbeeld van: je sleept een afbeelding op de pagina, de canvas API leest de pixels, een eigen bucket-quantisatie groepeert ze door elk kanaal terug te brengen tot zestien niveaus, en de dominante kleuren rollen eruit, allemaal op je eigen apparaat. De afbeelding gaat de browser niet uit. De enige plek op de site die wél iets verstuurt is het contactformulier, dat een bericht post naar een endpoint buiten de site, precies wat een contactformulier hoort te doen.

Technisch is de site zo opgezet dat client-side JavaScript de uitzondering is en niet de regel. Interactief zijn de tools zelf, het contactformulier en de kopieerknoppen; de rest, inclusief de 254 kleurpagina's met hun volledige conversietabellen, wordt server-gerenderd en vooraf gebouwd. Daardoor serveert de site vanaf de edge, zonder server-runtime die ergens hoeft te wachten. De omgevingsvariabelen zijn een handvol publieke NEXT_PUBLIC-waarden (de basis-URL, een verificatietoken, een schakelaar voor de advertentieslots en het endpoint van het contactformulier), stuk voor stuk met een werkende fallback, zodat een verse clone het zonder configuratie doet.

Naast de tools staat er een bibliotheek van 254 gecureerde kleuren, verdeeld over tien families: rood, oranje, geel, groen, cyaan, blauw, paars, roze, bruin en neutraal. Een kleur krijgt een eigen referentiepagina met de naam, de vijf notaties, tinten en schaduwen, pairings, het contrast op een licht en op een donker vlak, en kopieerklare CSS. Dat sluit aan op een reële zoekvraag ('crimson color hex', 'wat is de rgb van emerald') die per kleur klein is, maar over een paar honderd kleuren optelt.

De verleiding bij zo'n opzet is om er een pagina voor iedere mogelijke hexcode van te maken. Dat zijn zestien miljoen pagina's die allemaal bijna identiek zijn, en dat is het soort onbegrensde crawl-ruimte waar een jong domein aan kapotgaat. We hebben die deur bewust dichtgezet: de route genereert alleen de gecureerde lijst en staat op dynamicParams = false, dus een hexcode die niet in de bibliotheek zit krijgt een 404 in plaats van een nieuwe pagina. Dat is een van de dingen die in de eerste week na oplevering uit onze eigen audit kwam en direct is gerepareerd.

De dataset is één bron van waarheid. Het aantal kleuren wordt afgeleid uit de lijst zelf en niet ergens in de teksten hardgecodeerd, de sitemap loopt over dezelfde lijst, en de OpenGraph-afbeeldingen ook. Groeit de bibliotheek, dan groeit alles mee zonder dat er ergens een getal blijft staan dat niet meer klopt. Diezelfde lijst maakt van de bibliotheek bovendien een netwerk in plaats van een stapel losse pagina's: de tinten, schaduwen en pairings op een kleurpagina worden opgezocht in de lijst, en zitten ze erin, dan zijn het links naar die kleurpagina's. Zitten ze er niet in, dan blijft het een swatch die je aanklikt om te kopiëren, zodat er geen link ontstaat naar een pagina die niet bestaat. Dat het losse README-tabelletje ondertussen een verouderd aantal bleek te noemen, laat precies zien waarom die regel in de code zelf de juiste plek is.

Omdat de pagina's vooraf gebouwd worden, staat er weinig tussen de inhoud en een crawler. De tool- en kleurpagina's hebben een eigen title, een eigen meta description, een canonical en OpenGraph-tags, één h1, semantische landmarks en gelabelde inputs met zichtbare focus. In de sitemap staan 279 URL's: 25 vaste paden en de 254 kleurpagina's, die uit dezelfde lijst worden afgeleid als de pagina's zelf. Bewust zonder lastModified, want een sitemap die bij iedere build dezelfde datum op alles stempelt, leert crawlers alleen maar om dat signaal te negeren.

Gestructureerde data zit op het niveau van de pagina zelf: WebApplication op de tools, FAQPage op de pagina's met een veelgestelde-vragenblok, CollectionPage op de bibliotheek, en WebPage plus BreadcrumbList op de kleurpagina's. De OpenGraph-afbeeldingen worden gegenereerd met next/og, en ook daar geldt de statische regel: ze worden tijdens de build meegebakken in plaats van bij het eerste verzoek gerenderd, zodat een deel op sociale media meteen een plaatje heeft.

Sommige dingen leer je pas door zelf te onderhouden. Next vervangt het openGraph-object per route-segment in plaats van het samen te voegen met dat van de layout, waardoor og:image en og:type stilletjes wegvielen op pagina's die hun eigen title en description meegaven. Dat zagen we terug in een externe audit, en de oplossing zit nu als gedeelde helper in de site-config, met de uitleg erbij zodat het niet opnieuw gebeurt. Verder zijn er de kleinere zaken die een site af maken: een description die op 155 tekens wordt afgekapt zonder een woord doormidden te breken, een robots-route, een llms.txt die de tools en de bibliotheek uitschrijft voor AI-crawlers, en een IndexNow-script dat nieuwe pagina's meteen aanmeldt.

HueKit is live op huekit.co en draait sinds de eerste commit op 2 juli 2026. Het is geen prototype dat na oplevering stilstaat: in de weken erna is de spider-trap op de kleurpagina's gesloten, is er een eigen 404 gekomen, zijn de OpenGraph-afbeeldingen toegevoegd, zijn de long-tail conversieroutes uitgebreid en zijn de bevindingen uit een externe site-audit weggewerkt. Het domein is jong, dus de eerlijke stand van zaken is dat de fundering nu klopt en de autoriteit nog moet komen.

Bij dat onderhoud hoort ook de vraag hoe zo'n site zichzelf ooit terugverdient. De laatste ronde heeft daarvoor de ruimte alvast gereserveerd: er staan advertentieslots op de tool-pagina's en er is een consent-banner, allebei achter een schakelaar die vandaag uit staat, zodat ze niets renderen en er geen layout shift ontstaat. De slots hebben een vaste minimale hoogte, zodat het aanzetten later de pagina niet alsnog laat verspringen. Wat we niet doen, is het antwoord eronder begraven; dat was tenslotte de reden om te beginnen.

Wat de site aantoont, is dat een vraag met veel zoekvolume niet automatisch een verzadigde markt is als de bestaande antwoorden traag en onvolledig zijn. En dat je zo'n antwoord kunt bouwen zonder infrastructuur: geen server, geen database, alleen statische bestanden, eigen code en een merk dat bij het onderwerp past. Voor ons is HueKit onderdeel van hoe we werken. We bouwen dit soort sites voor onszelf, brengen ze naar productie en houden ze bij, van het designsysteem tot de kleurwiskunde tot de gestructureerde data. Wat we voor opdrachtgevers doen, doen we dus eerst op eigen risico op ons eigen werk, en dat is de reden dat we weten wat er in de praktijk misgaat en hoe je het repareert.