Ik heb productieprojecten met alle drie deze CMS-systemen gebouwd in de afgelopen vier jaar. Sommige waren groene-weiland-projecten, anderen waren migraties van WordPress of verouderde systemen die uit elkaar vielen. Elke keer wanneer een klant mij vraagt "welke headless CMS zouden we moeten gebruiken?", weersta ik de neiging om een one-size-fits-all antwoord te geven — maar na het opleveren van tientallen projecten door 2025 en in 2026, heb ik sterke meningen ondersteund door echte praktijknarben.

Dit artikel analyseert Contentful, Sanity en Payload CMS langs de dimensies die werkelijk belangrijk zijn wanneer je iets echts bouwt: prijsstelling op schaal, developer experience in de praktijk, flexibiliteit van contentmodellering, API-design, en de dagelijkse redactionele workflow die jouw contentteam zal adoreren of haten.

Inhoudsopgave

Contentful vs Sanity vs Payload: Headless CMS Comparison 2026

Het 30-secondenoverzicht

Contentful is de zittende macht. Het bestaat sinds 2013 en drijft bedrijfssites op schaal aan. Het is gepolijst, betrouwbaar en duur.

Sanity is de favoriete van ontwikkelaars met zijn real-time, gestructureerde content-aanpak en aanpasbare studio. Het is krachtig maar heeft een leercurve en een prijsmodel dat je kan verrassen.

Payload is de newcomer die stiekem een serieuze speler is geworden. Het is open-source, standaard zelf te hosten (nu met een cloud-optie), geschreven in TypeScript, en rekent nul licentiekosten. In 2025 is Payload 3.0 uitgebracht met een complete rewrite bovenop Next.js, en dat veranderde alles.

Functie Contentful Sanity Payload
Type SaaS SaaS (self-host studio) Open Source / Self-hosted
Taal N/A (alleen API) JavaScript/React TypeScript/Next.js
Licentiekosten Ja Ja (op basis van gebruik) Geen (MIT)
GraphQL Ja Ja (GROQ voorkeur) Ja (automatisch gegenereerd)
REST API Ja Ja Ja (automatisch gegenereerd)
Realtime-samenwerking Beperkt Uitstekend Goed (2.0+)
Self-hosting Nee Alleen studio Volledige stack
Database Eigendomsrecht Eigendomsrecht MongoDB of Postgres

Prijsanalyse: wat je werkelijk gaat betalen

Dit is waar het echt wordt. Prijsstelling is de voornaamste reden waarom ik teams heb zien overschakelen naar een ander CMS midden in een project, en het is het voornaamste wat mensen onderschatten tijdens de evaluatie.

Contentful-prijsstelling (2026)

De gratis laag van Contentful biedt je 1 space, 5 gebruikers en 25K API-aanroepen. Dat is prima voor een blog.

Het Basic-abonnement begint bij €300/maand en geeft je meer omgevingen en rollen. Het Premium-abonnement — wat de meeste serieuze teams nodig hebben — wordt op maat geprijsd maar begint meestal rond €2.000-€3.000/maand voor middelgrote organisaties. Ik heb bedrijfscontracten gezien boven de €80K/jaar.

De vuistslag: API-aanroepoverschrijdingen. Contentful berekent Content Delivery API-aanroepen, Content Management API-aanroepen en bandbreedte van activa afzonderlijk. Op een site met veel verkeer die 10M+ paginaweergaven/maand doet, kunt u gemakkelijk voorbij inbegrepen quota gaan. Een klant waarmee ik werkte zag hun maandelijkse rekening springen van €2.500 naar €4.800 na een viral productlancering vanwege CDN- en API-overschrijdingen die ze niet hadden verwacht.

Sanity-prijsstelling (2026)

Sanity gebruikt een op gebruik gebaseerd model dat ze "pay as you grow" noemen. Het gratis abonnement omvat 3 niet-admin-gebruikers, 500K API-verzoeken, 20GB bandbreedte en 10GB opslag. Royaal voor het begin.

Het Growth-abonnement is €15/gebruiker/maand plus gebruiksoverschrijdingen. Het Enterprise-abonnement wordt op maat geprijsd.

Dit is het moment dat Sanity-prijsstelling mensen bijt: GROQ-query's en API CDN-verzoeken worden gemeten, en de kosten schalen met uw content-complexiteit. Een enkele GROQ-query die diep geneste, gereferentieerde content ophaalt, kan meer van uw quota verbruiken dan u zou verwachten. Sanity heeft hier transparantie verbeterd, maar ik raad teams nog steeds aan om vroeg budgetwaarschuwingen in te stellen.

Typische middelgrote projectkosten: €200-€800/maand afhankelijk van teamgrootte en verkeer.

Payload-prijsstelling (2026)

Payload is MIT-gelicentieerd. Het CMS zelf kost €0. Voor altijd. Er zijn geen per-seat-kosten, geen API-aanroepmetering, geen bandbreutekosten van Payload.

Je kosten zijn infrastructuur: het hosten van een Node.js-app en een database. Op een service zoals Railway, Render of een basis AWS/DigitalOcean-setup, kijk je naar €20-€100/maand voor de meeste projecten. Zelfs een grootschalige implementatie met beheerde Postgres op AWS RDS, een goed gegroeide EC2 of ECS-setup en CloudFront ervoor overschrijdt zelden €300-€500/maand — en dat is voor serieus verkeer.

Payload Cloud (hun gehoste aanbod) begint bij €50/maand met plannen die schalen op basis van opslag en bandbreedte, maar het is volledig optioneel.

Scenario Contentful Sanity Payload (zelf gehost)
Solo-ontwikkelaar, kleine site €0 (gratis laag) €0 (gratis laag) €20-40/mnd (hosting)
5-persoonsteam, middelmatig verkeer €300-500/mnd €200-400/mnd €50-100/mnd (hosting)
10-persoonsteam, veel verkeer €2.000-4.000/mnd €500-1.500/mnd €150-400/mnd (hosting)
Enterprise, 50+ redacteurs €5.000-10.000+/mnd €2.000-5.000/mnd €300-800/mnd (hosting)

Het prijsverhaal is ondubbelzinnig. Payload wint op kosten in elke categorie.

Developer Experience

Prijsstelling brengt mensen aan de deur. Developer experience houdt ze daar — of drijft ze weg.

Contentful DX

De developer experience van Contentful is... prima. Hun SDK-ondersteuning is breed (JavaScript, Python, Ruby, Java, Swift, enz.), documentatie is volwassen, en de REST- en GraphQL-API's zijn goed gedocumenteerd.

Maar hier is wat me frustreert: alles wordt geconfigureerd via de web-UI. Content types, velden, validaties — het is allemaal klik-klik-klik in de browser. Ja, je kunt de Contentful CLI en migratiescripts gebruiken om je schema onder versiebeheer te plaatsen, maar het voelt zoals iets extra's. Het is niet code-first; het is UI-first met een code-ontsnappingsluik.

De migratietoolset is verbeterd met hun contentful-migration-pakket, maar vergeleken met het definiëren van je schema in TypeScript en onmiddellijke type-safety? Het voelt een generatie achter.

Sanity DX

De developer experience van Sanity is op veel manieren werkelijk uitstekend. Het schema wordt gedefinieerd in JavaScript/TypeScript-bestanden. De studio is een React-app die je uitgebreid kunt aanpassen — aangepaste invoercomponenten, aangepaste weergaven, workflow-plugins.

GROQ, hun querytaal, is krachtig als je het eenmaal leert. Maar "als je het eenmaal leert" doet veel zwaar werk in die zin. GROQ is niet SQL. Het is niet GraphQL. Het is zijn eigen ding, en elke nieuwe ontwikkelaar in je team moet het leren. Ik heb junior-ontwikkelaars GROQ-projecties zien worstelen gedurende weken.

// GROQ-query - krachtig maar unieke syntaxis
*[_type == "post" && publishedAt < now()] | order(publishedAt desc) [0...10] {
  title,
  slug,
  "author": author->{ name, image },
  "categories": categories[]->{ title, slug },
  body[] {
    ...,
    _type == "image" => {
      "url": asset->url
    }
  }
}

De real-time-functies van Sanity zijn echter ongelooflijk. Meerdere redacteurs werken aan hetzelfde document met aanwezigheidsindicatoren en geen opslagconflicten — het werkt gewoon. De content lake-architectuur maakt dit op manieren mogelijk die de concurrenten niet kunnen.

Payload DX

Payload 3.0 veranderde alles. Gebouwd op Next.js, volledig geschreven in TypeScript, met je configuratiebestand als de enkele bron van waarheid. Je definieert collections, velden, hooks, toegangscontrole en aangepaste endpoints allemaal in code.

Hier is hoe een typische Payload-collectie eruitziet:

import { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
    defaultColumns: ['title', 'status', 'publishedAt'],
  },
  access: {
    read: () => true,
    create: ({ req: { user } }) => Boolean(user),
    update: ({ req: { user } }) => Boolean(user),
    delete: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'content',
      type: 'richText',
    },
    {
      name: 'author',
      type: 'relationship',
      relationTo: 'users',
    },
    {
      name: 'status',
      type: 'select',
      options: ['draft', 'published'],
      defaultValue: 'draft',
    },
    {
      name: 'publishedAt',
      type: 'date',
      admin: {
        position: 'sidebar',
      },
    },
  ],
  hooks: {
    beforeChange: [
      ({ data, operation }) => {
        if (operation === 'create') {
          data.publishedAt = new Date()
        }
        return data
      },
    ],
  },
}

Alles is getypeerd. Je IDE vult veldnamen aan. Hooks geven je levenscycluscontrole. Toegangscontrole wordt gedefinieerd als functies naast je velden, niet in een afzonderlijke machtigingen-UI. En omdat het gewoon een Next.js-app is, kun je aangepaste pagina's, API-routes of server-acties naast je CMS-code toevoegen.

Voor teams die Next.js-ontwikkeling doen, is Payload 3.0 vanuit een DX-perspectief een no-brainer. Je CMS en je frontend leven in hetzelfde project. Dezelfde implementatie. Dezelfde repository.

Contentful vs Sanity vs Payload: Headless CMS Comparison 2026 - architecture

Content Modeling

Content modeling is waar je jezelf instelt voor succes of een nachtmerrie creëert waarmee je jaren zult leven.

De aanpak van Contentful

Contentful gebruikt een traditioneel content type → entry-model. Je definieert content types met velden, en redacteurs maken entries. Verwijzingen tussen content types zijn expliciet. Het werkt goed voor rechtstreekse content-structuren.

De beperkingen tonen zich met rich text. Het rich text-veld van Contentful slaat content op als een gestructureerde JSON-tree, wat geweldig is voor renderingflexibiliteit, maar het modelleren van complexe paginaindelingen met geneste componenten vereist creatief gebruik van ingebedde entries en verwijzingen. Het kan omslachtig worden.

Contentful ondersteunt 50 content types in het Basic-abonnement en 100+ in Premium. Voor grote sites met veel content types kan dit een beperking worden.

De aanpak van Sanity

De content modeling van Sanity is wellicht het meest flexibel van de drie. Hun block content (Portable Text) is een open specificatie voor rich text die content opslaat als gestructureerde gegevens. Je kunt aangepaste bloktypen, inline-objecten en aantekeningen definiëren.

Het schemasysteem ondersteunt diep geneste objecttypen, voorwaardelijke velden en aangepaste validatie. Ik heb enkele werkelijk complexe content-modellen in Sanity gebouwd die pijnlijk zouden zijn in Contentful.

// Sanity-schema met Portable Text-aanpassing
export default {
  name: 'post',
  type: 'document',
  fields: [
    {
      name: 'body',
      type: 'array',
      of: [
        { type: 'block',
          marks: {
            annotations: [
              { name: 'internalLink', type: 'object',
                fields: [{ name: 'reference', type: 'reference', to: [{ type: 'post' }] }]
              }
            ]
          }
        },
        { type: 'image', options: { hotspot: true } },
        { type: 'codeBlock' },
        { type: 'callout' },
      ]
    }
  ]
}

De aanpak van Payload

De content modeling van Payload zit ergens tussen de gestructureerde eenvoud van Contentful en de vormeloosheid van Sanity — maar met het voordeel dat het volledig in TypeScript zit.

Het blocks-veld van Payload is bijzonder krachtig voor paginabouw. Je definieert bloktypen, elk met hun eigen velden, en redacteurs kunnen pagina's samenstellen uit deze blokken. Gecombineerd met het layout-veldtype en voorwaardelijke logica, kun je bijna alles modelleren.

De Lexical rich text-editor van Payload 3.0 is een uitstekend onderdeel. Het verving Slate (wat prima was maar oud) met een moderne editor die aangepaste knooppunten, inline-blokken en server-side rendering uit het vak ondersteunt. Je kunt React-componenten rechtstreeks in rich text-content inbedden.

Het versiebeheersysteem verdient vermelding. Payload geeft je concept/publiceer-workflows en volledige documentversiegeschiedenis met diffing. Dit is ingebouwd, niet een betaalde add-on.

APIs: REST, GraphQL en alles ertussenin

Contentful API's

Contentful biedt afzonderlijke API's voor levering (CDN-gecached, alleen-lezen), voorbeeld (niet-gecached, concept-content), beheer (CRUD) en afbeeldingen. De scheiding is verstandig maar betekent dat je jongliert met meerdere API-tokens en basis-URL's.

Hun GraphQL API is stevig, maar heeft dieptebeperkingen en tarieflimieten die frustrerend kunnen zijn bij het modelleren van diep gereferentieerde content. Complexe query's kunnen meerdere rondes vereisen.

Sanity API's

De primaire querytaal van Sanity is GROQ, bediend via HTTP. Ze bieden ook een GraphQL API, maar deze voelt als een burger van de tweede soort. GROQ is voor de meeste Sanity-use cases toch krachtiger.

De echte magie is de real-time listener API van Sanity. Je kunt je abonneren op wijzigingen op elke query en onmiddellijke updates krijgen. Dit maakt live preview-ervaringen mogelijk die werkelijk indrukwekkend zijn.

Payload API's

Payload genereert automatisch zowel REST als GraphQL API's uit je collection-configs. Geen extra setup. Definieer een collectie, krijg onmiddellijk volledige CRUD-endpoints voor zowel REST als GraphQL.

# Automatisch gegenereerde GraphQL-query
query {
  Posts(where: { status: { equals: published } }, sort: "-publishedAt", limit: 10) {
    docs {
      id
      title
      content
      author {
        name
      }
      publishedAt
    }
    totalDocs
    hasNextPage
  }
}

Maar hier is waar Payload een uniek voordeel heeft: omdat het in hetzelfde proces als je Next.js-app draait, kun je de API overslaan en de Local API van Payload gebruiken voor server-side gegevensphazing. Directe databasequery's met dezelfde toegangscontrole, hooks en validatie — maar met nul HTTP-overhead.

// Local API - geen HTTP, geen serialisatie-overhead
const posts = await payload.find({
  collection: 'posts',
  where: { status: { equals: 'published' } },
  sort: '-publishedAt',
  limit: 10,
})

Dit is een enorme prestatie-winst voor server-gerenderde pagina's. Geen netwerkronde-trip naar een CMS API. Gewoon een functieaanroep.

Redactionele Experience

Ontwikkelaars kiezen het CMS, maar redacteurs leven erin dagelijks. Negeer hun ervaring niet op eigen risico.

Contentful heeft de meest volwassen redactionele UI. Het is schoon, voorspelbaar, en je niet-technische team zal het snel oppikken. De planning, workflows en goedkeuringsketen in het Premium-abonnement zijn stevig. Het kan echter rigide aanvoelen — het aanpassen van de redactionele interface vereist het bouwen van een Contentful App, wat een hele aparte React-app is.

Sanity Studio is het meest aanpasbaar. Je kunt geheel op maat gemaakte bewerkingservaringen bouwen. Maar die aanpassing komt met kosten: uit het vak kan Sanity Studio overweldigend aanvoelen voor niet-technische redacteurs. De structuurbouwer vereist ontwikkelaarstijd om goed te configureren.

Het admin-panel van Payload is dramatisch verbeterd in 3.0. Het is schoon, snel (het is een Next.js-app) en ondersteunt aangepaste componenten, voorwaardelijk veldrendering en live voorbeeld. Het is niet zo gepolijst als Contentful's UI, maar het is aanpasbaaarder met minder moeite dan Contentful en toegankelijker uit het vak dan Sanity.

Self-hosting versus SaaS: de werkelijke afwegingen

Dit is de filosofische scheiding. Contentful en Sanity zijn SaaS-platforms. Je beheert geen infrastructuur; je betaalt hen om het te doen. Payload wordt standaard zelf gehost.

Het SaaS-argument: minder ops-overhead, ingebouwde CDN, beheerde uptime. Dit zijn echte voordelen, vooral voor kleine teams zonder DevOps-ervaring.

Het self-hosted-argument: eigendom van gegevens, geen vendor lock-in, voorspelbare kosten, naleving van regelgeving (GDPR, HIPAA, gegevenslocatie) en vrijheid alles aan te passen.

Voor agentschappen zoals het onze die headless CMS-ontwikkeling doen, is self-hosting in 2026 aanbevolen voor de meeste klanten. De infrastructuurgereedschappen zijn volwassen geworden tot het punt waarop het implementeren van een Payload-app op Railway, Vercel of AWS ongecompliceerd is. Docker maakt het reproduceerbaar. En de kostenbesparing ten opzichte van een SaaS CMS stapelt zich jaar na jaar op.

Als je bezorgd bent over de ops-belasting, verwerkt Payload Cloud hosting voor je terwijl je de voordelen van open-source behoudt.

Prestaties en schaalbaarheid

De CDN-backed delivery API van Contentful is snel. Typische responsetijden zijn 50-100ms van edge-knooppunten. Het is tien jaar lang getest op schaal.

De CDN API van Sanity levert vergelijkbare prestatie af voor gecachede content, waarbij hun real-time layer misschien 20-30ms toevoegt voor live query's.

De prestatie van Payload hangt af van je infrastructuur, maar hier is het ding — wanneer je de Local API met Next.js server-componenten gebruikt, roep je een functie aan naar een lokale database. Responsetijden kunnen onder de 10ms liggen. Voeg een CDN voor je Next.js-output toe (Vercel, CloudFront, enz.) en je evenaart of slaat de SaaS-opties.

Voor op Astro gebaseerde projecten werken alle drie goed als API-bronnen, maar de REST- en GraphQL-API's van Payload zijn bijzonder ongecompliceerd om in Astro's data-phazing-laag te consumeren.

Ecosysteem en Community

Contentful heeft het grootste enterprise-ecosysteem. Tonnen integraties, een marketplace met apps, en wijdverbreide agency-ondersteuning.

Sanity heeft een gepassioneerde ontwikkelaargemeenschap, uitstekende documentatie en een groeiend plugin-ecosysteem. Hun community Slack is werkelijk nuttig.

Payload heeft de snelst groeiende gemeenschap van de drie. Hun Discord is uiterst actief, en het kernteam reageert regelmatig op vragen. Het plugin-ecosysteem is kleiner maar groeit snel — en omdat Payload gewoon Node.js/TypeScript is, kun je alles wat je nodig hebt npm installeren.

De GitHub van Payload heeft meer dan 30K sterren vanaf begin 2026 en de traject is steil.

Het oordeel

Ik zal direct zijn: Payload is het beste headless CMS voor de meeste projecten in 2026.

Hier is waarom:

  1. Nul licentiekosten op elke schaal. Je 50-editor enterprise-team betaalt Payload geen stuiver.
  2. TypeScript-native config betekent dat je content-model code is, onder versiebeheer, type-veilig en beoordeelbaar in PRs.
  3. Local API + Next.js-integratie geeft je prestaties die SaaS CMS'sen fysiek niet kunnen bereiken.
  4. Eigendom van gegevens — je content leeft in je database, niet in iemand anders' eigendomsrecht-winkel.
  5. Geen vendor lock-in — als je weg wilt schakelen, je gegevens staan in Postgres of MongoDB. Gewoon query het.

Er zijn scenario's waar de anderen winnen:

  • Kies Contentful als je een grote enterprise bent met een gevestigd contentteam dat een gepolijste, nul-ops redactionele ervaring nodig heeft en het budget heeft.
  • Kies Sanity als real-time samenwerking kritiek voor je workflow is, je Portable Text's ongeëvenaarde gestructureerde rich text nodig hebt, of je een zeer aangepaste studio-ervaring bouwt.
  • Kies Payload voor alles anders. Startups, agentschappen, mid-market-bedrijven, door-ontwikkelaars geleide teams, gereglementeerde industrieën die gegevenscontrole nodig hebben, en iedereen die niet wakker wil worden van een verrassing op de rekening.

Als je een headless CMS voor een nieuw project evalueert en de specifieke gegevens door wilt nemen, helpen we graag. We hebben productie Payload-, Sanity- en Contentful-projecten opgeleverd en kunnen je eerlijk advies geven op basis van je werkelijke vereisten en budget.

Veelgestelde vragen

Is Payload CMS echt gratis? Ja. Payload is MIT-gelicentieerde open-source-software. Er zijn geen licentiekosten, geen per-user-kosten en geen API-aanroeplimieten van Payload zelf. Je enige kosten zijn hosting-infrastructuur (server en database), die meestal €20-€500/maand kost afhankelijk van schaal. Payload Cloud is beschikbaar als een betaald gehoste optie als je liever geen infrastructuur beheert.

Kan Sanity zelf gehost worden? Gedeeltelijk. Sanity Studio (de admin-UI) is een React-app die je overal kunt implementeren. De content lake — waar je werkelijke gegevens zich bevinden — is echter een gehoste service beheerd door Sanity. Je kunt de gegevenslaag niet zelf hosten. Dit betekent dat je content altijd op Sanity's infrastructuur leeft, wat een probleem kan zijn voor gegevenslocatie of nalevingsvereisten.

Welk headless CMS heeft de beste GraphQL-ondersteuning? Contentful en Payload bieden beide sterke GraphQL API's. Payload genereert automatisch zijn GraphQL-schema rechtstreeks uit je collection-configs, wat betekent nul handmatig schema-onderhoud. De GraphQL API van Contentful is volwassen en goed gedocumenteerd. Sanity biedt GraphQL aan maar verkiest GROQ als zijn primaire querytaal, en hun GraphQL-implementatie ondersteunt niet alle GROQ-functies.

Is Contentful in 2026 de moeite waard? Voor grote bedrijven met complexe content-operaties, bestaande Contentful-workflows, en teams die een praktische SaaS-aanpak waarderen — ja, het kan de moeite waard zijn. Voor kleine-tot-middelgrote teams is de kosten steeds moeilijker te rechtvaardigen wanneer Payload vergelijkbare (en op sommige manieren superieure) functionaliteit biedt tegen een fractie van de prijs. We hebben meerdere klanten zien migreren van Contentful specifiek vanwege kosten.

Hoe handelt Payload CMS beeldoptimalisatie af? Payload heeft ingebouwde beeldgrootte wijzigen en brandpuntkroppping. Wanneer je een afbeelding uploadt, kan Payload automatisch meerdere maten genereren op basis van je config. In Payload 3.0 met Next.js kun je dit combineren met Next.js Image-optimalisatie voor responsief, WebP/AVIF-bediening. Het is niet zo functieverrijkt als de afbeeldingen-API van Contentful (die URL-gebaseerde transformaties biedt), maar het dekt 90% van de use cases zonder een service van derden.

Kan ik van Contentful naar Payload migreren? Ja. Omdat Payload standaarddatabases gebruikt (Postgres of MongoDB), omvat migratie het exporteren van je Contentful-content via hun Management API en het importeren in Payload-collecties. De content-modellering-translatie van Contentful content types naar Payload-collecties is meestal ongecompliceerd. We hebben verschillende van deze migraties verwerkt — het ingewikkeldste deel is doorgaans rich text-conversie, niet de gestructureerde gegevens.

Welk CMS is het beste voor niet-technische redacteurs? Contentful heeft de meest intuïtieve out-of-the-box redactionele ervaring voor niet-technische gebruikers. Het admin-panel van Payload is dicht bij en verbetert snel. Sanity Studio kan het beste van alle drie zijn als een ontwikkelaar tijd investeert in het aanpassen, maar de standaardevaring heeft een steilere leercurve voor redacteurs.

Werkt Payload CMS met frameworks anders dan Next.js? Absoluut. Hoewel Payload 3.0 Next.js als admin UI-framework gebruikt, werken de REST- en GraphQL-API's met elk frontend — Astro, Nuxt, SvelteKit, Remix, of zelfs mobiele apps. De Local API is Next.js-specifiek, maar de externe API's hebben geen framework-afhankelijkheden. We koppelen regelmatig Payload aan zowel Next.js als Astro afhankelijk van projectvereisten.