We bouwen twee soorten software op twee verschillende stacks. Bedrijfsapplicaties, zoals klantportalen, koppelingen en financiële toepassingen, maken we op .NET en Azure. Marketingsites maken we met Next.js. Per soort software kiezen we de stack waar het onderhoud het best te regelen is.
Na de kritieke lekken in PHP, de programmeertaal onder WordPress en veel andere websites, van oktober 2026 ligt de vraag voor de hand of dat de reden is dat onze marketingsites niet op WordPress draaien. Dat is het niet. Next.js kreeg in dezelfde maand zelf kritieke lekken.
Elke stack krijgt vroeg of laat een lek. Wat telt, is wie er dan wat doet.
Twee soorten software
Bedrijfsapplicaties bevatten de logica, data en rechten waar een organisatie op draait. Denk aan een klantportaal waar klanten hun eigen gegevens inzien en aanleveren, of aan een koppeling die facturen, betalingen en klantgegevens tussen systemen uitwisselt. Een fout in zulke software raakt de bedrijfsvoering. Deze software beheren we jaren. Samen met de klant ontwikkelen we die verder.
Die applicaties bouwen we op .NET en Azure, het platform van Microsoft. Azure regelt inloggen, rechten en opslag in één omgeving en sluit aan op de Microsoft-diensten die in veel organisaties al in gebruik zijn. Nieuwe applicaties bouwen we volgens dezelfde vaste opzet.
Een marketingsite vraagt iets anders. De klant wil zelf teksten, beelden en pagina's aanpassen zonder een ontwikkelaar te bellen. De site moet snel laden en goed vindbaar zijn. Het ontwerp moet over een paar jaar nog kloppen, ook na honderden wijzigingen door redacteuren.
Daarvoor gebruiken we Next.js, met Sanity voor het contentbeheer en Vercel voor de hosting. Site en applicatie houden we gescheiden. Gevoelige klantgegevens blijven in de applicatie. De site verwijst ernaar, bijvoorbeeld met een knop naar het klantportaal.
Waarom niet alles in .NET
Dat kan. Eén stack voor alles heeft ook voordelen: één taal, één manier van bouwen en één manier van beheren.
Voor marketingsites wegen andere dingen zwaarder. Next.js is gebouwd voor websites. Snelheid en vindbaarheid in zoekmachines zitten er standaard in.
Sanity is gebouwd voor redacteuren. Een redacteur ziet bij het bewerken direct hoe de pagina eruit komt te zien en werkt met velden die wij per site inrichten. In .NET is dat allemaal te bouwen, maar dan bouwen en onderhouden we het zelf. Bij Next.js en Sanity zit het erin en houdt een grote gemeenschap het bij.
Voor een applicatie ligt de afweging andersom. Daar wegen betrouwbaarheid, de beveiliging van gegevens en de aansluiting op Microsoft-diensten zwaarder dan het gemak voor een redacteur.
Waarom niet WordPress
WordPress is de bekendste keuze voor websites. Het heeft een volwassen beheeromgeving, veel thema's en voor bijna elke functie een plugin. Voor een kleine site is dat snel en betaalbaar.
Het onderhoud zit vooral in die plugins. Elke plugin is code van een andere partij, met een eigen updateritme. Volgens Patchstack zat ruim negen op de tien gevonden kwetsbaarheden in het WordPress-ecosysteem in een plugin.
Daarnaast staat veel van een WordPress-site in instellingen in het beheerscherm, buiten de code. Welke instelling wanneer is aangepast, is daardoor lastig na te gaan. Bij onze marketingsites ligt de hele opbouw van de site vast in code, met een geschiedenis van elke wijziging. Alleen de teksten en beelden staan in Sanity.
Wat de keuze oplevert
- Geen eigen server. Er is geen server die wij of de klant moeten bijhouden. Dat scheelt onderhoud.
- Een redacteur ziet alleen wat hij nodig heeft. Ontwerp en techniek blijven buiten bereik.
- Gangbare techniek. Next.js behoort tot de meest gebruikte technieken voor websites. Dat geeft zekerheid voor de lange termijn: de site blijft goed te onderhouden en door te ontwikkelen.
Wie bijwerkt bij een lek
Bij een WordPress-site werken de hostingpartij en de beheerder van de site zelf bij: PHP op de server en de plugins in de site. Bij een beheerde dienst als Vercel neemt het platform een deel over. Hoe groot dat deel is, verschilt per lek. Soms zijn sites op het platform niet kwetsbaar, soms zet het platform een extra afscherming neer en blijft bijwerken nodig.
De site zelf bijwerken blijft daarom ons werk, net als bij de applicaties.
De afweging
Voor bedrijfsapplicaties ligt het onderhoud bij ons en Microsoft, voor marketingsites bij ons en Vercel. De veiligheid van een site zit niet in de naam van de stack. Die zit in wie hem bijwerkt als er een lek is en hoe snel dat gebeurt.