Ik ben de afgelopen vijf jaar tientallen WordPress-sites gemigreerd naar headless architecturen. Sommige van die migraties waren absoluut de juiste keuze -- de teams zagen snellere pagina's laden, minder beveiligingsincidenten en konden features uitbrengen die WordPress gewoon niet aankon. Maar ik heb ook talloze teams van migratie afgehouden. WordPress draait meer dan 43% van het web, en het eruit gooien alleen maar omdat "headless cool is" is een dure fout.

Dit artikel is het eerlijke beslissingskader dat ik zelf graag had gekregen toen ik naar een WordPress-site staarde die 8 seconden nodig had om te laden en afvroeg of ik alles in brand moest steken. We behandelen de echte signalen dat je WordPress bent ontgroeid, waar je in 2026 naartoe migreert, en hoe je de beslissing neemt zonder zes maanden en een kwart miljoen dollar te verspillen.

Inhoudsopgave

7 tekenen dat je WordPress bent ontgroeid: Wanneer over te schakelen naar headless in 2026

De WordPress Realiteitscheck: Wat is er eigenlijk veranderd in 2026

Laten we het recht zetten. WordPress 6.7+ is aanzienlijk beter geworden. Full Site Editing is nu volwassen. Het performance-team heeft echte verbeteringen uitgebracht -- lazy loading, speculative prerendering, en de Performance Lab plugin hebben de gat gedicht. Als je WordPress draait op een solide host zoals Cloudways of Kinsta met een goed gebouwde theme, kun je absoluut een snelle site serveren.

Maar hier is het ding: die verbeteringen hebben een plafond. WordPress is nog steeds een monolitische PHP-applicatie die HTML rendert op elk verzoek (tenzij je caching eroverheen legt, wat zijn eigen complexiteit introduceert). De databasegestuurde architectuur die WordPress flexibel maakt, is dezelfde architectuur die het langzaam maakt onder druk.

Ik ben niet tegen WordPress. Ik ben tegen pretenderen dat elk gereedschap voor elke situatie werkt. Dus laten we praten over wanneer WordPress werkelijk ophoudt het juiste gereedschap te zijn.

7 tekenen dat je WordPress bent ontgroeid

Dit zijn geen theoretische problemen. Dit zijn patronen die ik herhaaldelijk heb gezien in client-engagements bij Social Animal, en dit zijn de signalen die me doen zeggen "ja, het is tijd."

Teken 1: Je paginaladingstijden worden slechter ondanks optimalisatie

Je hebt al het basiswerk gedaan. Je draait WP Rocket of W3 Total Cache. Je hebt Cloudflare ervoor staan. Je hebt afbeeldingen geoptimaliseerd met ShortPixel. Je hebt render-blocking CSS opgeruimd. En je Largest Contentful Paint is op mobiel nog steeds boven de 3 seconden.

Als je het optimalisatiespelboek hebt uitgeput en je bent nog steeds niet boven de Core Web Vitals-drempels, dan vecht je tegen de architectuur, niet tegen de implementatie.

Teken 2: Je beheert meer dan 30 plugins

Elke plugin is een dependency. Elke dependency is een potentieel beveiligingsgat, een performance hit en een compatibiliteitsrisico bij de volgende WordPress-update. Ik audieerde vorig jaar een site van een klant die 47 actieve plugins had. Zevenveertig. De plugin-belasting alleen voegde 1,2 seconden toe aan elk niet-cached verzoek.

Teken 3: Je ontwikkelaarsteam gruwelt ervan ermee te werken

Dit wordt ondergewaardeerd. Als je developers meer tijd besteden aan het bestrijden van WordPress dan aan het bouwen van features -- worstelen met ACF veldgroepen, debuggen van plugin-conflicten, proberen Gutenberg blocks dingen te laten doen waarvoor ze niet zijn ontworpen -- betaal je een verborgen belasting op elke sprint.

Moderne frontend developers willen werken in React, TypeScript en component-gebaseerde architecturen. Ze willen in 2026 geen PHP-template bestanden schrijven. Developer velocity doet ertoe.

Teken 4: Je hebt functies nodig waarvoor WordPress niet is gebouwd

Real-time dashboards. Complexe authenticatiestroom. Multistap-wizards met conditionele logica. Gepersonaliseerde inhoud op basis van gebruikersgedrag. Op rollen gebaseerde toegangscontrole die verder gaat dan subscriber/editor/admin.

Ja, je kunt dit allemaal aan WordPress vastkoppelen met plugins en aangepaste code. Maar op een bepaald moment bouw je in wezen een aangepaste applicatie binnen een CMS dat is ontworpen voor blogberichten. De fundering past niet bij het gebouw.

Teken 5: Beveiligingsincidenten worden een patroon

Als je in de afgelopen 12 maanden meer dan één beveiligingsincident hebt meegemaakt -- malware-injecties, brute force-aanvallen die erdoorheen kwamen, plugin-kwetsbaarheden die werden uitgebuit voordat je kon patchen -- is het een signaal. WordPress's massieve marktaandeel maakt het het #1-doelwit voor geautomatiseerde aanvallen. Sucuri's 2024 rapport toonde aan dat WordPress meer dan 96% van de geïnfecteerde CMS-sites representeerde.

Teken 6: Je verkeersspikes veroorzaken downtime

Je wordt aanbevolen in een podcast. Een tweet gaat viral. Je Black Friday-verkoop slaat aan. En je site gaat offline. Je kunt meer serverresources eraan gooien, zeker. Maar als je $200-500/maand betaalt voor managed WordPress-hosting alleen om af en toe verkeersspikes aan te kunnen, betaal je te veel voor een probleem dat static/edge-gedeployde sites voor $20/maand oplossen.

Teken 7: Je draait meerdere eigenschappen uit één contentbron

Een marketing-site, een mobiele app, een partnerportaal en een intern dashboard -- allemaal het dezelfde content nodig. WordPress's REST API kan dit theoretisch allemaal serveren, maar het was achteraf vastgekoppeld. De performance en developer experience van doelmatig gebouwde headless CMS API's liggen in een ander segment.

De performancegrens: Wanneer verkeer WordPress breekt

Laten we over getallen praten. Dit is wat ik heb waargenomen op echte websites:

Metriek WordPress (Geoptimaliseerd) Headless (Next.js/Vercel) Headless (Astro/Cloudflare)
TTFB (niet-cached) 400-800ms 50-150ms 20-80ms
TTFB (cached) 100-200ms 50-150ms 20-80ms
LCP (mobiel) 2,5-4,5s 1,0-2,0s 0,8-1,5s
Gelijktijdige gebruikers voor degradatie 500-2.000 50.000+ (edge) 100.000+ (static)
Maandelijkse hostingkosten op schaal $100-500 $20-100 $0-20
Buildtijd (500 pagina's) N.v.t. (dynamisch) 30-90s 15-45s

Dit zijn geen synthetische benchmarks. Dit zijn bereiken van echte productiesites. De kloof op TTFB is bijzonder sprekend -- als elk paginaverzoek een PHP-proces en een MySQL-database raakt, is er een ondergrens waar je niet onderuit kunt komen, ongeacht hoeveel caching je toevoegt.

Het edge-deployment-model dat Next.js op Vercel en Astro op Cloudflare Pages gebruiken, is fundamenteel anders. Je inhoud wordt vooraf gegenereerd en bediend vanaf het CDN edge-knooppunt dat het dichtst bij de gebruiker ligt. Er is geen origin-server in het kritieke pad voor de meeste verzoeken.

Voor teams die met verkeersschalingsproblemen te kampen hebben, hebben we onze aanpak voor Next.js development en Astro development gedocumenteerd die specifiek op deze performance-patronen ingaat.

7 tekenen dat je WordPress bent ontgroeid: Wanneer over te schakelen naar headless in 2026 - architectuur

Pluginbloat: De stille moordenaar

Dit is hoe een typische WordPress-pluginstack eruitziet voor een middelgrote marketing-site:

# De "essentiële" pluginstack die 2-3 seconden toevoegt aan elk verzoek
Yoast SEO                    # ~50ms
WPForms Pro                  # ~40ms
WP Rocket                    # ~30ms (ironisch)
Wordfence Security           # ~80ms
Advanced Custom Fields Pro   # ~60ms
WPML (meertalig)             # ~120ms
WooCommerce (zelfs basaal)   # ~200ms
Elementor Pro                # ~150ms
MonsterInsights              # ~40ms
UpdraftPlus                  # ~20ms
Redirection                  # ~15ms
Smush Pro                    # ~30ms

Dat is 835ms pluginoverhead op elk niet-cached paginaverzoek. En dit is een bescheiden stack. Ik heb sites gezien waar pluginuitvoering alleen al 2+ seconden duurt.

Het headless equivalent? Het meeste van deze functionaliteit bestaat niet op serverniveau (SEO wordt bij buildtijd verwerkt, beveiliging wordt door het hostingplatform verwerkt, formulieren worden door de frontend verwerkt) of het wordt vervangen door doelmatig gebouwde services die geen PHP-executiecontext delen.

// In een Next.js headless-setup zijn je "plugins" npm-packages
// die alleen worden geladen als ze werkelijk nodig zijn
import { generateMetadata } from '@/lib/seo'     // Alleen buildtijd
import { Analytics } from '@vercel/analytics'      // Client-side, lazy-loaded
import { submitForm } from '@/lib/forms'           // On-demand, edge function

Het architectuurverschil is dat headless concerns scheidt. Je CMS handelt inhoud af. Je frontend handelt presentatie af. Je edge functions handelen dynamische logica af. Niets concurreert om hetzelfde PHP-proces.

Beveiliging in 2026: WordPress versus headless

WordPress-beveiliging is niet inherent slecht. Het kernteam doet solide werk. Maar het ecosysteem creëert een massale aanvalsoppervlak:

  • Plugin-kwetsbaarheden: Patchstack rapporteerde meer dan 5.900 nieuwe WordPress-plugin-kwetsbaarheden in 2024. Dat getal is ieder jaar stijgende.
  • Credentiaal-aanvallen: wp-login.php en xmlrpc.php worden constant door geautomatiseerde scanners getest.
  • Bestandssysteem-toegang: WordPress heeft schrijftoegang nodig tot zijn eigen bestanden voor updates, wat betekent dat een gecompromitteerde plugin kernbestanden kan wijzigen.
  • Database-blootstelling: SQL-injectie blijft een topaanvalsvector omdat elke plugin directe databasetoegang heeft.

Een headless-architectuur vermindert dit aanvalsoppervlak drastisch. Je frontend bestaat uit statische bestanden op een CDN -- er is niets te hacken. Je CMS zit achter authenticatie en is niet openbaar toegankelijk. Je API-laag kan worden vergrendeld naar specifieke eindpunten met rate limiting.

Hier is de beveiliging-modelcomparison:

Aanvalsvector WordPress Headless-architectuur
Openbaar admin-panel Ja (wp-admin) Nee (CMS achter VPN/auth)
Plugin-kwetsbaarheden Hoog risico (30+ plugins) Minimaal (npm packages, geen serveruitvoering)
SQL-injectie Mogelijk via plugins Alleen CMS, niet openbaar toegankelijk
DDoS-kwetsbaarheid Server-rendered, CPU-intensief Statisch/edge, trivialaal schaalbaar
Bestandssysteem-aanvallen Schrijftoegang vereist Geen schrijfbaar bestandssysteem
Brute force-login Veelvoorkomend doelwit CMS niet openbaar blootgesteld

Aangepaste functies die WordPress niet aankan

Laat me je specifieke voorbeelden van echte projecten geven:

Interactieve productconfigurators

Een klant had een 3D-productconfiguratie nodig met real-time prijsstelling. In WordPress betekende dit een React-app ingebed in een shortcode, tegen Elementor vecht voor DOM-controle, jQuery EN React op dezelfde pagina laden. Na migratie naar Next.js met een headless CMS was de configurator een native deel van de applicatie met gedeelde state management en proper code splitting.

Multi-tenant dashboards

Een andere klant had klant-facing dashboards nodig die data uit meerdere API's trokken, met op rollen gebaseerde toegang en real-time updates. We probeerden dit in WordPress te bouwen met aangepaste post types en de REST API. Het authenticatiemodel alleen -- proberen WordPress's cookie-gebaseerde auth uit te breiden om met JWT-tokens voor API-toegang te werken -- was een nachtmerrie.

Met Next.js, Supabase voor authenticatie en real-time data, en Payload CMS voor contentbeheer, kostte dezelfde featureset de helft van de ontwikkelingtijd en presteerde tien keer beter.

Geinternationaliseerde inhoud met complexe routing

WPML kost $99-199/jaar en voegt aanzienlijke overhead toe. Next.js heeft ingebouwde geinternationaliseerde routing. Astro ondersteunt i18n native. De content modeling in headless CMS-platforms zoals Payload handelt gelokaliseerde velden als een eerste-klassenconcept af, niet als een plugin-nasleep.

Het keuzeraamwerk voor headless stack

Oké, dus je hebt besloten dat WordPress je niet meer volstaat. De volgende vraag is: waarmee bouw je? Dit is hoe ik in 2026 over de beslissing denk.

Frontend-framework: Next.js versus Astro

Factor Next.js Astro
Het beste voor App-achtige ervaringen, dashboards, e-commerce Contentsites, blogs, marketing sites
Interactiviteit Volledige React SPA-mogelijkheden Islands-architectuur (minimale JS standaard)
Performance (static) Uitstekend Uitstekend
Performance (dynamisch) Uitstekend met RSC Goed met server islands
Leercurve Gemiddeld (React-kennis vereist) Lager (HTML-first, multi-framework)
Ecosysteem Massief (React-ecosysteem) Snel groeiend
Deployment Vercel, Netlify, Cloudflare, self-hosted Cloudflare, Netlify, Vercel, elke static host
2026 prijzen (Vercel Pro) $20/lid/maand $0-20/maand (meeste hosts)

Kies Next.js wanneer: Je geauthenticeerde gebruikerservaringen nodig hebt, complexe client-side state, real-time functies, of je team kent al React. Bekijk onze Next.js development mogelijkheden voor de soorten projecten waar dit uitblinkt.

Kies Astro wanneer: Je site is vooral content-gericht, je wilt absolute snelste performance met minimale JavaScript, of je team prefereert een eenvoudiger mentaal model. We dekken dit uitgebreid af in onze Astro development practice.

CMS: Payload versus Sanity versus Contentful

// Payload CMS 3.0 -- self-hosted, volledige controle
// Je schema IS je TypeScript-code
import { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'content', type: 'richText' },
    { name: 'author', type: 'relationship', relationTo: 'users' },
    { name: 'publishedAt', type: 'date' },
  ],
  access: {
    read: () => true,
    create: ({ req: { user } }) => user?.role === 'editor',
  },
}

Ik heb Payload CMS 3.0 in 2026 zwaar aan teams die migreren van WordPress aanbevolen. Dit is waarom:

  • Self-hosted: Geen vendor lock-in, geen verrassingen in per-seat-prijzen. Host het op Railway of Render voor $7-20/maand.
  • Code-first: Je content schema is TypeScript. Versiebeheersing. Type-veilig. Geen klikken via GUI-menu's.
  • Gebouwd op Next.js: Het admin-panel draait op Next.js, dus je team gebruikt één framework voor alles.
  • Gratis en open source: De core is MIT-gelicenseerd. Geen verrassingsrekeningen.

Voor teams die een gehoste oplossing prefereren, blijft Sanity uitstekend (gratis tier genereus, $99/maand voor teams). Contentful is nog steeds de enterprise-keuze op $300+/maand, maar de prijsstelling heeft veel mid-market teams naar alternatieven gedwongen.

We werken met al deze platforms in onze headless CMS development practice.

Backend/Database: Supabase

Als je headless project gebruikers authenticatie, real-time data of databasetoegang buiten wat de CMS biedt nodig heeft, is Supabase om goede redenen de standaardkeuze geworden:

  • PostgreSQL onder de motorkap (geen proprietaire database)
  • Ingebouwde auth met sociale providers, magic links en row-level security
  • Real-time subscriptions uit de doos
  • Edge functions voor serverless logica
  • Gratis tier handelt de meeste MVP's af; Pro-plan is $25/maand
// Supabase real-time subscription in een Next.js component
import { createClient } from '@supabase/supabase-js'

const supabase = createClient(url, anonKey)

// Abonneer je op nieuwe orders in real-time
const channel = supabase
  .channel('orders')
  .on('postgres_changes', 
    { event: 'INSERT', schema: 'public', table: 'orders' },
    (payload) => {
      console.log('Nieuwe order:', payload.new)
    }
  )
  .subscribe()

Probeer dat in WordPress zonder een $200 plugin en een WebSocket-server die je zelf moet onderhouden.

Migratieplanning: De eerlijke tijdlijn

Laat me eerlijk zijn over tijdslijnen omdat ik veel bureaus zie die WordPress-naar-headless migraties noemen in 4-6 weken. Dat is ofwel een heel eenvoudige site ofwel iemand liegt.

Site-complexiteit Content-volume Realistische tijdlijn Budgetbereik (2026)
Eenvoudige marketing (10-20 pagina's) Laag 4-8 weken €13.500-27.000
Mid-size met blog (50-200 pagina's) Gemiddeld 8-14 weken €27.000-67.500
E-commerce (500+ producten) Hoog 14-24 weken €67.500-180.000
Enterprise multi-site Zeer hoog 24-40 weken €135.000-360.000+

De grootste tijdverspillers, in volgorde:

  1. Content migratie en herstructurering (30% van totale inspanning) -- Je WordPress-content model wijkt waarschijnlijk niet netjes toe aan een headless CMS. Je moet het herstructureren.
  2. Design en frontend development (35%) -- Je bouwt nieuwe templates/components, je migreert niet zomaar PHP-bestanden.
  3. Functionaliteit recreatie (20%) -- Formulieren, zoeken, e-commerce, integraties -- alles moet opnieuw worden gebouwd of vervangen.
  4. Testen en QA (15%) -- SEO redirect-mapping, gebroken link-checking, cross-browser testen.

Voor een eerlijk gesprek over wat je specifieke migratie zou inhouden, neem contact op met ons team. We zeggen je of het het waard is voordat we iets citeren.

Wanneer je NIET moet migreren

Ik beloofde eerlijkheid, dus hier is het. Migreer niet van WordPress als:

  • Je site een eenvoudige blog of brochure site is en het werkt goed. WordPress is geweldig hiervoor. Repareer niet wat niet stuk is.
  • Je team geen JavaScript developers heeft. Een headless stack vereist frontend development-vaardigheden. Als je team alleen PHP is, is de leercurve aanzienlijk.
  • Je bent zwaar afhankelijk van WordPress-specifieke plugins zonder headless equivalenten. WooCommerce's volledige functieset, membership plugins zoals MemberPress, LMS plugins zoals LearnDash -- deze hebben ecosystemen gebouwd rond WordPress die lastig te herhalen zijn.
  • Je budget onder de €13.500 ligt. Een juiste migratie kost echt geld. Onderfinancierde migraties eindigen slechter dan de WordPress-site die ze vervingen.
  • Je hebt alleen maar beter hosting nodig. Soms is het antwoord niet een nieuwe architectuur -- het is verhuizen van GoDaddy naar Kinsta. Probeer dat eerst.
  • Je hebt geen duidelijke reden behalve "WordPress voelt oud." Gevoelens zijn geen business case. Definieer de specifieke problemen, kwantificeer de kosten, en beslis vervolgens.

Als je WordPress-site in onder de 2 seconden laadt, je team features in het tempo kan bouwen dat het bedrijf nodig heeft, en je hebt geen beveiligingsincidenten mee te maken -- blijf op WordPress. Serieus.

Je kunt onze prijspagina checken om te begrijpen wat een migratie-investering werkelijk kost en besluiten of de ROI voor je situatie zin heeft.

Veelgestelde vragen

Hoeveel kost het om van WordPress naar een headless CMS te migreren? Voor een middelgrote marketing-site met 50-200 pagina's verwacht je €27.000-67.500 voor een juiste migratie in 2026. Dit omvat content migratie, frontend development, functionaliteit recreatie en SEO-behoud. Eenvoudige sites kunnen voor €13.500-27.000 worden gedaan, terwijl enterprise of e-commerce sites €135.000+ kunnen kosten. De kosten zijn hoger dan een WordPress redesign, maar de lange-termijn hosting, beveiliging en onderhoudsbesparingen maken de ROI vaak positief binnen 12-18 maanden.

Verlies ik mijn SEO-rangschikkingen als ik van WordPress naar headless migreer? Niet als je het goed doet. De kritieke stappen zijn: dezelfde URL-structuur behouden (of juiste 301 redirects instellen voor elke pagina), alle meta tags en structured data behouden, zorgen dat je sitemap correct wordt gegenereerd en de nieuwe sitemap direct na lancering indienen bij Google Search Console. Ik heb sites zien verbeteren in rangschikkingen na migratie omdat Core Web Vitals scores aanzienlijk sprongen. Maar ik heb ook botste migraties zien het verkeer met 60% doen dalen omdat iemand vergat redirects toe te wijzen. Behandel SEO-migratie als een eersteklasses workstream, niet als een nagedachte.

Kan ik WordPress als headless CMS gebruiken in plaats van volledig migreren? Ja, en dit is eigenlijk een solide middenweg-aanpak. Je behoudt WordPress als je content-backend (met WPGraphQL of de REST API) en bouwt een Next.js of Astro frontend. Je editors houden de admin-interface die ze kennen, en je krijgt moderne frontend performance. De minuspunten: je hebt nog steeds WordPress om te onderhouden en veilig te stellen, de REST API en WPGraphQL voegen overhead toe in vergelijking met doelmatig gebouwde headless CMS API's, en je draait twee systemen in plaats van één. Het is een goede transitiestap, maar de meeste teams schakelen uiteindelijk over naar een dedicated headless CMS.

Is Payload CMS echt gratis? Wat is het addertje onder het gras? Payload CMS 3.0 is werkelijk open source onder de MIT-licentie. Geen per-seat prijzen, geen gebruikscapaciteitslimiet. Het addertje onder het gras is dat je het self-host, dus je bent verantwoordelijk voor infrastructuur -- hoewel hosting op Railway, Render of een VPS eenvoudig is en goedkoop ($7-25/maand). Payload biedt een cloud hosting optie voor teams die de infrastructuur niet willen beheren, startend rond $50/maand. Vergeleken met Contentful's $300+/maand teamplan is het een aanzienlijk kostenverschil.

Hoe lang duurt een WordPress naar headless migratie? Realistisch gezien 8-14 weken voor een middelgrote site. Dat is niet 8-14 weken kalenderijd met één developer -- het is een gefocuste inspanning met een klein team (meestal 2-4 personen). De grootste tijdinvestering is content herstructurering en frontend development. Migraties die dit proberen te haasten eindigen met technical debt die maanden kost op te ruimen. Als een bureau je 2-3 weken citeert voor iets behalve een eenvoudige brochure site, stel je harde vragen over wat wordt besneden.

Moet ik Next.js of Astro kiezen voor mijn headless frontend? Als je site vooral content is (blog, marketing site, documentatie), geeft Astro je betere performance met minder complexiteit. Het verstuurt standaard nul JavaScript en hydratiseert alleen interactieve components. Als je geauthenticeerde ervaringen, complexe client-side interacties of real-time functies nodig hebt, is Next.js de betere keuze omdat je het volledige React-ecosysteem krijgt. Veel teams gebruiken beide -- Astro voor de marketing site en Next.js voor de webapplicatie. Beide zijn in 2026 uitstekende keuzes.

Wat gebeurt er met mijn WordPress-plugins als ik naar headless ga? Ze gaan niet met je mee. De functionaliteit van elke plugin moet ofwel: opnieuw worden gemaakt in je nieuwe stack, worden vervangen door een SaaS-service (bijv. Formspree voor formulieren, Algolia voor zoeken), of worden bepaald onnodig te zijn. Dit is eigenlijk één van de voordelen van migratie -- je bent gedwongen om te auditen wat je werkelijk nodig hebt versus wat door de jaren heen is opgehoopt als "gewoon een plugin voor dat installeren." De meeste sites ontdekken dat ze slechts 30-40% van hun pluginfunctionaliteit nodig hebben.

Is headless overkill voor een kleine bedrijfswebsite? Vaak wel, ja. Als je een site hebt met 10 pagina's, een blog, een contactformulier en geen aangepaste applicatielogica, is WordPress op goede hosting (Kinsta, WP Engine, Cloudways) waarschijnlijk de juiste keuze. Het is goedkoper om te bouwen, makkelijker om zonder developers te onderhouden, en de content editing experience is volwassen. Headless begint zin te maken wanneer je performance ceilings raakt, aangepaste functies bouwt, meerdere content kanalen beheert of schaalt voorbij wat één WordPress-instance aankan. Voeg architectuurcomplexiteit die je niet nodig hebt niet toe.