SubnetKit

Een subnet uitrekenen is geen zeldzame taak. Een beheerder die een netwerk opdeelt, een developer die een security group dichtzet, een student die zich door subnetting-oefeningen worstelt: ze stellen dezelfde kleine, scherpe vragen. Wat is het broadcast-adres van 192.0.2.0/26. Hoeveel bruikbare hosts passen er in een /29. Welke poort is dat ook alweer. Het zijn vragen met één juist antwoord, en dat antwoord hoort binnen een seconde op het scherm te staan.

In de praktijk gebeurt dat vaak niet. De tools die je bovenaan tegenkomt zijn opgebouwd rond advertentieruimte in plaats van rond het invoerveld, laden trager dan de berekening zelf ooit zou duren, en leveren het antwoord af in een tabel waar je zelf de juiste rij uit moet vissen. Voor een handeling die tien seconden zou moeten kosten, is dat veel wrijving. De concurrentieanalyse in seo-strategy.md bevestigde waar de opening zit: er staat een site zonder noemenswaardige domeinautoriteit op plek acht, dus autoriteit is hier geen harde toegangspoort. De wig zit in gebruikservaring en diepgang.

We hebben de site vanuit die belofte opgezet en die in de strategie vastgelegd voordat er een regel code stond. De calculators werken zonder aanmelding en zonder limiet, en er staat vandaag geen advertentie op de site: in de gebouwde HTML zit geen extern script, geen font-CDN en geen analytics-tag. Eerlijk is wel dat de code inmiddels een advertentieslot en een consent-banner bevat. Die renderen niets zolang NEXT_PUBLIC_ADS_ENABLED niet op true staat, bewust zo gebouwd dat we later kunnen aanzetten zonder dat de layout verspringt. Het doel dat in seo-strategy.md staat is expliciet in die volgorde: eerst autoriteit opbouwen, dan natuurlijke backlinks verdienen door iets te maken dat mensen uit zichzelf willen delen, en pas daarna verkeer. Dat is een langzamere route dan een pagina volplempen met keywords, maar het is de route waar we op durven bouwen.

SubnetKit heeft geen CSS-framework en geen thema. Het design-systeem staat in één stylesheet die volledig voor deze site is geschreven. De opening van dat bestand legt de keuze vast: een light-first developer-docs esthetiek, een koele neutrale grijsschaal en één accentkleur, een cyaan (#0891b2 in het lichte thema, #22b8d6 in het donkere). Verder niets. Geen tweede accent, geen kleurverloop, geen decoratie die om aandacht vraagt terwijl je naar een getal zit te kijken.

De onderbouwing daarvan is inhoudelijk. Dit is gereedschap, geen etalage. Het onderwerp is technische documentatie, en de visuele taal die netwerkmensen de hele dag lezen is die van een goede handleiding: rustig, hoog contrast, alles op zijn plek. Eén regel drukt dat samen: monospace is er voor adressen, masks en binaire waarden, en verder niet. Cijfers die je moet overtikken of vergelijken staan in een vaste letterbreedte, lopende tekst niet. Dat klinkt klein, maar het is het verschil tussen een octet kunnen scannen en hem moeten spellen.

Het systeem is ook bewust anders gezet dan dat van de naburige sites in ons netwerk, zoals in de code staat aangetekend: geen donkere terminal, geen leiblauw dashboard. Een merk verdient een eigen gezicht, ook als het van dezelfde makers komt. Er zit geen externe font-CDN in, alleen een systeemfont-stack, waardoor er niets render-blokkerends te wachten valt. Het donkere thema wordt vóór de eerste paint gezet door een kort inline script dat localStorage leest en anders naar de systeemvoorkeur kijkt, zodat wie in het donker werkt geen witte flits krijgt.

Onder de site ligt een verzameling pure TypeScript-functies zonder afhankelijkheden. In lib/ipv4.ts zit de IPv4-wiskunde: calcSubnet, prefixToMask, maskToPrefix, de binaire weergave, route-summarisatie en het opsplitsen van netwerken, inclusief de randgevallen die er in de praktijk toe doen. Een /31 heeft geen apart broadcast-adres en levert twee bruikbare adressen op (RFC 3021), een /32 is één host: dat soort uitzonderingen is precies waar de meeste calculators de mist in gaan. lib/ipv6.ts doet de IPv6-kant en rekent met BigInt, omdat 128 bits niet in een JavaScript-number passen. lib/convert.ts doet de basisconversies en de MAC-normalisatie. De calculators en de referentiepagina's rekenen met deze functies, dus wat de /26-pagina zegt en wat de calculator zegt komt uit hetzelfde stuk code.

Op twee plekken wijken we daar bewust van af, en dat is het vermelden waard omdat het een keuze met een prijs is. Het script dat de JSON-API genereert draagt zijn eigen kopie van de CIDR-wiskunde, zodat het als los Node-script kan draaien zonder TypeScript-toolchain. De insluitbare widget draagt een tweede kopie in plain JavaScript, zodat hij één zelfstandig bestand blijft zonder framework eromheen. Beide zetten dat in hun eigen kopcommentaar. Het generatorscript leest de poortendataset wel uit lib/ports.ts, dus die gegevens hebben één bron; de widget rekent uitsluitend subnetten uit en draagt zelf geen poortdata mee. Voor de IPv4-wiskunde geldt dat niet: dat zijn drie implementaties, en er staat op dit moment niets in de repo dat afdwingt dat ze gelijk blijven. Wie de kern aanpast, moet de kopieën nalopen. Dat is de rekening die hoort bij een dependency-vrij script en een widget van één bestand, en die noemen we liever dan dat we hem verstoppen.

De site is verder statisch. Next.js 16 App Router met React 19, alles voorgerenderd, TypeScript in strict mode. De productieafhankelijkheden zijn op te sommen in één adem: next, react en react-dom. De vijf dynamische routes staan op dynamicParams: false naast hun lijst met vooraf gebouwde paden, dus wat niet vooraf gebouwd is, bestaat niet en zet ook geen server aan het werk. Voor de bezoeker vertaalt dat zich in twee dingen. Snelheid, omdat een pagina die al af is niets meer hoeft te berekenen en je invoer direct in je eigen browser wordt verwerkt zonder netwerkronde. En privacy, in de letterlijke betekenis: het interne bereik dat je in een calculator plakt gaat nergens heen, want er is geen endpoint dat calculatorinvoer ontvangt. De uitzondering hoort erbij vermeld, want die is er: het contactformulier op /contact post wel naar een endpoint van ons eigen netwerk, anders kan niemand ons bereiken. In de huisregels van de repo staat om dezelfde reden dat voorbeeldadressen uit de documentatiebereiken komen, zoals 192.0.2.0/24 en 2001:db8::/32, en dat er geen AI-functies in de site zitten.

De zoekvraag in deze niche is niet één vraag maar honderden varianten, en zo'n variant verdient zijn eigen antwoord op zijn eigen URL. Daarom genereren we uit de datasets een aparte pagina per CIDR-prefix van /0 tot en met /32 (33 stuks), per poort (150), per poortcategorie (20) en per gangbaar host-aantal (24). Daar komen 8 handgeschreven guides en 22 vaste pagina's bij: de acht calculators, de hubs per sectie en de juridische pagina's. Samen zijn dat 257 voorgerenderde pagina's. De sitemap leest uit dezelfde datasets en telt vandaag dezelfde 257 URL's als de build oplevert.

Belangrijker dan het aantal is waar het ophoudt. De host-pagina's beantwoorden de omgekeerde vraag, namelijk welk blok je nodig hebt voor zoveel hosts, en die lijst is gecureerd in plaats van uitputtend: de ronde getallen die mensen echt intypen (50, 100, 200, 250) plus de 2^h-2-grenzen die in elk subnetting-vraagstuk terugkomen (14, 30, 62, 126, 254, 65534). In de code staat het onomwonden als regel opgeschreven, dat het nadrukkelijk niet uitputtend is en er geen pagina-per-getal komt. Dat onderscheid is het verschil tussen programmatische pagina's die ergens over gaan en een pagina-fabriek die zichzelf uiteindelijk uit de index werkt.

Diezelfde datasets voeden nog twee dingen. Een statische JSON-API onder public/api, zonder sleutel en zonder limiet, omdat de endpoints bestanden op een CDN zijn in plaats van een draaiende service; next.config.ts zet daar de CORS-header op plus een cache-regel van een uur met stale-while-revalidate erachter. En een insluitbare calculator die iemand met één iframe-regel in zijn eigen blog of documentatie zet. Beide zijn er omdat ze op zichzelf nuttig zijn, en omdat iets wat anderen willen gebruiken en citeren een duurzamere vorm van linkbuilding is dan een link die je zelf moet gaan vragen.

De SEO zit in de constructie in plaats van erbovenop. De routes zetten hun eigen metadata met een canonical en hun eigen JSON-LD, opgebouwd uit gedeelde builders voor WebApplication, FAQPage en BreadcrumbList, zodat een nieuwe pagina die structuur meekrijgt zonder dat iemand eraan hoeft te denken. Voor de Open Graph-beelden schreven we een eigen generator die een SVG-sjabloon met @resvg/resvg-js naar 1200x630 PNG rasteriseert, om de eenvoudige reden dat sociale platforms geen SVG als og:image renderen. Die PNG's staan meegecommit in de repo en worden bewust niet bij elke build gemaakt, omdat de build-machines de gebruikte fonts niet hebben.

De prijs van die keuze is een handmatige stap, en die stap is nu zichtbaar achterstallig. Na het toevoegen van tools, guides of poorten moet npm run og lokaal draaien om de set bij te trekken, en dat is bij de laatste uitbreidingen niet gebeurd. De prefix- en poortpagina's hebben hun eigen beeld, maar de host-pagina's en de poortcategorieën verwijzen naar een PNG die nog niet gegenereerd is, en van de acht guides hebben er vijf een beeld. Dat is geen ramp, want het raakt alleen hoe een gedeelde link er op LinkedIn uitziet, maar het staat hier omdat het precies laat zien wat een handmatige stap in een verder automatische keten kost. Het is het eerste dat we voor go-live rechttrekken.

Sommige beslissingen zijn juist beslissingen om iets níét te doen. De sitemap zet bewust geen lastModified, omdat het stempelen van de builddatum op iedere URL bij elke deploy crawlers alleen maar leert dat signaal te negeren. De keywordmap houdt één primair zoekwoord per pagina aan om kannibalisatie te voorkomen, en uit de poort-cluster hebben we de zoekwoorden over het porteren van telefoonnummers geschrapt: ze delen het woord, niet de bedoeling. De link naar het bredere netwerk is er één, met een natuurlijke anchor, in plaats van een sitewide linkwiel. Twee zelfgeschreven verifiers houden het geheel eerlijk: de crawler leest de gebouwde HTML en faalt op een gebroken interne link of een weespagina, op twee bewuste uitzonderingen na (de homepage en de embed-widget, die van niemand een link hoeven te krijgen), en de schemacontrole parseert de JSON-LD-blokken en meldt een inhoudspagina zonder schema of een blok waarin een verplicht veld ontbreekt. Ze zijn losse commando's in plaats van een stap in de build, en de afspraak in post-launch.md is dat ze samen met de build voor elke deploy draaien. Ze werken tegen de echte build-output in plaats van tegen de broncode, en vangen daarom wat een linter mist. Bij de laatste run kwamen ze allebei schoon door. Daarnaast wordt bij elke build een llms.txt gegenereerd, zodat de site ook machineleesbaar is voor wie er anders naar kijkt dan een klassieke crawler.

SubnetKit is sinds begin juli 2026 in ontwikkeling en is deploy-klaar voor de Vercel-vrije laag, of voor een andere statische host. De laatste stappen uit de launch-checklist staan nog open: het domein met DNS en SSL naar Vercel wijzen, NEXT_PUBLIC_SITE_URL zetten en de verificatie in Search Console en Bing afronden. Het onderhoudsprofiel is wel zoals we het wilden: geen server om te patchen, geen database om te back-uppen, geen calculatorinvoer die wij ontvangen of kunnen lekken. Uitbreiden betekent een item aan een dataset toevoegen, waarna de pagina, de sitemap-regel en het API-endpoint uit zichzelf volgen; alleen de OG-afbeelding vraagt om die ene handmatige generatorstap. De poortendataset is van de 37 uit het oorspronkelijke plan doorgegroeid naar 150 zonder dat de templates mee moesten.

De site is jong en we doen hier geen uitspraken over verkeer, want die cijfers zeggen op deze termijn niets. Wat wel te controleren valt, is het werk zelf: 257 statische pagina's, 8 calculators, 150 poorten, 33 prefixes, drie productieafhankelijkheden, en een crawl en schemacontrole die schoon moeten zijn voordat er iets de deur uit gaat. Het plan daarna staat ook al op papier in plaats van in iemands hoofd: reverse-lookup-pagina's per subnetmask, IPv6-prefixpagina's, vergelijkingspagina's uit de 'mensen vragen ook'-vragen en een visuele subnet-splitter als tweede linkbait-asset, in golven van ongeveer twee maanden. Elke golf is een dataset-bewerking plus hooguit één nieuwe route. Dat is het fundament waar organisch verkeer op kan groeien, en het is het deel dat je daadwerkelijk in de hand hebt.

Voor wie overweegt met ons te werken is dit vooral een demonstratie van reikwijdte. SubnetKit is geen opdracht die wij hebben uitgevoerd maar iets wat we voor onszelf hebben bedacht, gepositioneerd, ontworpen, gebouwd en vindbaar gemaakt, en waar we nu zelf aan vastzitten voor het onderhoud. Die laatste toevoeging is de eerlijkste. De keuzes die je maakt als je zelf de rekening en het beheer krijgt, zijn andere keuzes dan die je maakt als je na oplevering vertrekt: je bouwt dan liever een dependency-vrije kern die je over twee jaar nog begrijpt dan een stapel packages die je vandaag snelheid geeft. Het laat ook zien wat we van onszelf verwachten als iets niet klopt, zoals die achterlopende OG-set: opschrijven, niet wegpoetsen. Dit is hoe wij bouwen als beide van ons zijn.