Unscrambly

Iemand zit vast met zeven letters op een rekje, of staart naar een jumble in de krant. De vraag die die persoon in een zoekbalk typt is heel precies en het antwoord is eindig: er is een woordenlijst, er zijn letters, en er is een set woorden die je daaruit kunt maken. Dat is een van de weinige zoekopdrachten waarbij je een bezoeker binnen een seconde volledig kunt bedienen. Precies daarom viel het ons op hoe slecht die niche bediend wordt.

De solvers die er staan hebben er een verdienmodel omheen gebouwd dat het antwoord in de weg zit. Je krijgt eerst een consentmuur, dan een pagina die grotendeels uit advertentieblokken bestaat, dan een formulier dat je letters naar een server stuurt, en pas daarna een lijst die zelden goed gesorteerd is. Het antwoord is er wel, maar het staat achter een wachtkamer. En verander je één letter, dan begint de wachtkamer opnieuw.

We wilden zien wat er overblijft als je die hele laag weghaalt. Geen accounts, geen serververzoek per zoekopdracht, en op dit moment ook geen advertentie- of analyticscode in de site: de ruimte die we voor advertenties gereserveerd hebben rendert niets zolang er geen netwerk is gekozen en aangezet, zodat er later ook geen layout shift ontstaat. Wat overblijft is een tool die doet wat de bezoeker vroeg, en dat is in deze niche kennelijk genoeg om onderscheidend te zijn.

Een woordspel-solver kan makkelijk overkomen als valsspelen: een kille, technische machine die het spel voor je oplost. We wilden juist dat de site aanvoelt als onderdeel van het spel zelf. Daarom zit het Scrabble-tegeltje in het hart van het merk. Het logo is een rijtje tegels, resultaten worden getoond als tegels met de letterwaarde klein in de hoek, en het OpenGraph-beeld dat we bij de bouw met next/og genereren laat het woord UNSCRAMBLY zien als tien tegels met slagschaduw, alsof ze op tafel liggen.

Het palet volgt diezelfde gedachte. Het canvas is warm crème (#fbf7ef), niet het gebruikelijke koele wit, met inkt in een zachte donkerbruine tint en tegels in een iets geler papierkleurtje (#fdf6e3). Het accent is een koraalrood (#f26449) dat de aandacht pakt zonder te schreeuwen, aangevuld met teal (#2f8f83) en goud (#e8b53d) voor scores en badges. Rustig en speels tegelijk, wat past bij een bordspel op een keukentafel en niet bij een dashboard.

Dat systeem staat in één handgeschreven stylesheet met een eigen set kleur- en maatvariabelen. Geen Tailwind, geen component-library, geen lettertype van een CDN: de typografie draait op de systeemletters die het apparaat al heeft, waardoor er geen extra verzoek nodig is om tekst te tonen. Aan runtime-code komt daar niets bij: next, react en react-dom, en verder alleen TypeScript en de bijbehorende typedefinities om mee te ontwikkelen. De donkere modus is geen omgekeerd filter maar een eigen tokenset, zodat het crème naar warm bruin gaat en de tegels donker hout worden in plaats van grijs.

De belangrijkste beslissing in dit project is architectonisch. De gangbare aanpak is om de woordenlijst op een server te houden en jouw letters daarheen te sturen. Wij draaiden dat om: de lijst van 269.870 speelbare woorden, van twee tot vijftien letters, gaat naar de browser en blijft daar. Het zoeken gebeurt op het apparaat van de bezoeker.

Dat kan alleen als het bestand klein genoeg is. We coderen de gesorteerde lijst front-coded, waarbij elk woord alleen opslaat hoeveel letters het deelt met zijn voorganger, en gzippen het resultaat. Wat er overblijft is één bestand van ongeveer 367 KB voor bijna 270.000 woorden. Het bestand staat niet in het kritieke pad: de pagina wordt eerst opgebouwd, en pas als de browser inactief is haalt de solver de lijst binnen, of eerder als de bezoeker het invoerveld aanraakt, zodat de eerste zoekopdracht meestal niet meer op de download hoeft te wachten. Daarna blijft de lijst een jaar lang immutable in de cache staan. Uitpakken doen we met de native DecompressionStream van de browser, wat betekent dat we geen gzip-bibliotheek hoeven mee te sturen.

Voor de bezoeker levert dat twee dingen op die je normaal tegen elkaar moet afwegen. Snelheid, omdat een volgende zoekopdracht geen netwerkverzoek meer kost en het antwoord dus direct verschijnt terwijl je letters aanpast. En privacy, niet als belofte in een privacyverklaring maar als gevolg van de architectuur: het zoeken kent geen endpoint waar je letters heen zouden kunnen. De solver heeft geen database en geen backend achter zich, dus daar valt ook niets te lekken of te onderhouden.

Bovenop die ene motor staan zes tools, elk met een eigen intentie: een anagram-solver die al je letters moet gebruiken, een Scrabble-woordzoeker die op punten sorteert, een Words With Friends-solver met de afwijkende puntentelling van dat spel, een descrambler, een woorden-met-deze-letters-tool en een Wordle-helper. Ze delen dezelfde code en dezelfde woordenlijst, maar verschillen in vaste opties, uitleg en de vragen die eronder beantwoord worden. Blanco tegels doen mee als wildcard: een vraagteken of een sterretje staat voor een onbekende letter, waarna de solver de mogelijke invullingen van dat vakje langsloopt. De score die je erbij ziet is de volle letterwaarde van het gevonden woord, want de puntentelling kijkt naar het woord en niet naar de vraag welke letter uit een blanco tegel kwam.

De solver en de woordpagina's rekenen met dezelfde scoremodule, dus wat je op een woordpagina leest komt overeen met wat de tool je live laat zien. Volledig doorgevoerd is dat principe nog niet: het buildscript dat de referentiepagina's genereert draagt zijn eigen kopie van de Scrabble-tabel, en het OpenGraph-beeld nog een derde. Ze geven dezelfde uitkomsten, maar het zijn drie plekken waar er één hoort te staan. Dat is precies het soort naad dat je op een site van deze omvang moet blijven zien, en het staat op de lijst om dicht te trekken.

Verder is er een woordpagina per woord, met de Scrabble-waarde, de Words With Friends-waarde, de anagrammen en de kortere woorden die in dat woord verstopt zitten. De pagina's die vanaf de site gelinkt worden zijn bij de bouw al uitgeschreven, dus ze zijn leesbaar zonder dat er ook maar één regel JavaScript draait. Staat een woord wel in de lijst maar nergens in de navigatie, dan wordt de pagina op aanvraag gerenderd: daarvoor reist de woordenlijst mee met de serverfunctie. Wie iets opvraagt dat geen woord is, krijgt een echte 404 en geen lege pagina die doet alsof. De route accepteert alleen twee tot vijftien kleine letters en controleert daarna of het woord echt in de lijst staat.

De sitemap telt 52.686 URL's. Naast tien vaste pagina's en de zes tools zijn dat 325 referentiepagina's en 52.345 woordpagina's. Die 325 vallen uiteen in 52 pagina's voor woorden die met een bepaalde letter beginnen of eindigen, 11 hubs voor N-letterwoorden, 252 combinaties van lengte en letter (zoals acht-letterwoorden eindigend op S) en 10 pagina's voor lastige letterparen zoals Q en Z. Elke pagina draagt een eigen canonical en eigen metadata, tot en met de dienstpagina's als over-ons en privacy: dat is basiswerk, daar maken we geen uitzonderingen op. Het onderscheid zit een laag hoger, in de JSON-LD. De tool-, referentie- en woordpagina's krijgen elk het schema dat bij hun type hoort, met overal een BreadcrumbList en een FAQPage, en op de toolpagina's daarbovenop een WebApplication met een nulprijs erin. De vier dienstpagina's hebben geen JSON-LD, want aan een privacyverklaring valt niets te structureren wat een zoekmachine verder helpt. De sitemap zelf wordt opgedeeld in shards van 5.000 URL's, ruim onder de limiet van 50.000 URL's per bestand.

De verleiding bij zoveel pagina's is om alles te genereren wat de combinatoriek toelaat. Dat hebben we bewust niet gedaan. Het buildscript schrijft alleen een pagina weg als een combinatie ten minste drie echte woorden oplevert, en de paginacatalogus slaat elke combinatie zonder data gewoon over. Van de 260 mogelijke combinaties van lengte en letter bleven er zo 252 over: acht pagina's die bijna leeg zouden zijn bestaan eenvoudigweg niet, zonder dat iemand daarvoor een uitzonderingslijst hoeft bij te houden. Voor de woordpagina's werkt het net zo: één functie bepaalt welke woorden ergens vandaan gelinkt worden, en diezelfde functie voedt zowel de sitemap als de voorrendering, zodat die twee niet los van elkaar bijgewerkt hoeven te worden.

En omdat een site van deze omvang niet met de hand te controleren is, hebben we de controle zelf ook gebouwd. Er zitten twee QA-scripts in de repo. Een crawler loopt de structurele pagina's en de referentiepagina's af, controleert of ze allemaal bereikbaar zijn en of er geen kapotte links tussen zitten, en trekt een steekproef van de woordpagina's om te bewijzen dat die route werkt. De 52.345 woordpagina's stuk voor stuk aflopen zou de crawler zinloos traag maken, dus dit is een rookmelder en geen volledige audit. Het tweede script haalt van elk paginatype dat JSON-LD draagt een voorbeeld op en controleert of de schema's kloppen. Allebei draaien ze tegen de productiebuild en niet tegen een aanname, en zo merken we ook wanneer de documentatie achterloopt op de code: de gegenereerde data is leidend, niet wat er ooit in een README is opgeschreven.

Unscrambly is sinds 2 juli 2026 in ontwikkeling en draait op Vercel. De site is jong en we doen geen uitspraken over verkeer: die cijfers zijn nog klein en zouden hier niets betekenen. Wat we wel kunnen laten zien is de staat van het werk. De build loopt schoon door TypeScript strict, de crawler vindt geen onbereikbare pagina's of kapotte links, en het draaiende geheel vraagt weinig: vrijwel alles is bij de bouw al uitgeschreven, en wat overblijft aan serverkant is de woordpagina op aanvraag.

Er liggen ook twee uitbreidingen klaar die verder gaan dan de site zelf. Er is een gratis JSON-API die uit voorgegenereerde bestanden bestaat, zonder sleutels en zonder rate limits, simpelweg omdat er niets is om te limiteren. En er is een insluitbare widget die andere sites in een iframe kunnen zetten. Allebei kosten ze niets extra's om te draaien, omdat ze dezelfde data gebruiken die de build toch al produceert.

Wat dit project laat zien is niet dat we een woordspel-solver kunnen maken. Het is dat we een merk, een design-systeem, een dataverwerkingsketen, een client-side applicatie en een SEO-architectuur van tienduizenden pagina's in één samenhangend geheel bouwen en daarna zelf onderhouden. Unscrambly is een van de 28 organische tool-sites die we in eigen beheer hebben gebouwd. Ze zijn ons eigen werk, wat betekent dat de keuzes erin ook onze eigen rekening zijn, en dat we van dichtbij zien wat ze kosten.