Waarom steeds meer organisaties kiezen voor Payload CMS
Van CMS naar digitale basis
Payload CMS is nog relatief nieuw. Versie 1.0 verscheen in juli 2022. Toch zien we de belangstelling voor het platform snel toenemen. Niet alleen bij start-ups en digitale bureaus, maar ook bij grote internationale organisaties. Microsoft, Vodafone, Mazda, ASICS en Sonos gebruiken Payload inmiddels voor websites, campagneplatformen, communities en interactieve applicaties.
Die groei is niet alleen te verklaren doordat Payload technisch modern is. Het platform sluit aan op een bredere behoefte. Organisaties willen hun digitale dienstverlening sneller kunnen aanpassen, minder afhankelijk worden van gesloten platformen en meer grip houden op hun eigen data, code en infrastructuur.
Tegelijkertijd bestaat het digitale landschap van veel organisaties uit steeds meer losse systemen. Er is een CMS voor de website, een afzonderlijk Digital Asset Management-systeem voor afbeeldingen en documenten, een intranet, een klantportaal en soms nog verschillende applicaties voor campagnes, formulieren en gebruikersbeheer. Al deze systemen hebben een eigen licentie, beheeromgeving en koppelingen nodig.
Payload kiest een andere benadering. Het is niet alleen een CMS, maar ook een applicatieframework, backend en mogelijke basis voor Digital Asset Management. Daardoor kan het verschillende onderdelen van het digitale landschap met elkaar verbinden of zelfs binnen één platform samenbrengen.
Dat maakt Payload vooral interessant voor organisaties die hun website niet langer als een los communicatiekanaal zien, maar als onderdeel van een breder digitaal platform.
Payload in de praktijk
Microsoft
Eigen infrastructuur en data-eigenaarschap waren belangrijke voorwaarden voor Microsoft Designer.
Bekijk de caseMazda
Payload verkortte ontwikkeltijden en gaf de marketingorganisatie meer grip op consistente contentblokken.
Bekijk de caseASICS
Een wereldwijd ambassadeursplatform ondersteunt honderden profielen, tientallen landen en duizenden aanmeldingen.
Bekijk de caseSonos
Een flexibel campagneplatform combineert contentbeheer, winkelgegevens en een privacyvriendelijk dashboard.
Bekijk de case
Microsoft: volledige controle over het platform
Voor de introductie van Microsoft Designer zocht Microsoft geen standaard CMS, maar een contentplatform dat op de eigen infrastructuur kon draaien. Data-eigenaarschap en het voorkomen van vendor lock-in waren belangrijke voorwaarden. Payload bood die controle, terwijl het ontwikkelteam wel direct kon werken met een moderne beheeromgeving, flexibele contentmodellen en API’s.
De case laat zien waarom Payload juist voor grote organisaties interessant is. De software schrijft de architectuur niet voor, maar sluit aan op bestaande beveiligings-, hosting- en ontwikkelprocessen. Daardoor kon Microsoft de publieksintroductie van een nieuwe AI-gedreven ontwerptool snel opbouwen, zonder de kritieke contentinfrastructuur onder te brengen bij een gesloten CMS-leverancier.
Lees de volledige Microsoft-case op https://payloadcms.com/case-studies/microsoft
Vodafone: een winkelervaring die redacteuren zelf beheren
Vodafone gebruikt Payload voor touchscreenapplicaties in winkels. Het oude platform presenteerde veel informatie tegelijk en maakte eenvoudige aanpassingen onnodig technisch. Samen met pemedia werd de ervaring opnieuw ontworpen in Figma, met duidelijke navigatie, grotere aanraakvlakken en een modulaire opbouw die direct naar beheersbare Payload-blokken is vertaald.
Daarmee verbeterde niet alleen het scherm voor bezoekers, maar ook het werk achter de schermen. Redacteuren kunnen content aanpassen zonder telkens een developer in te schakelen en het designsysteem bewaakt de samenhang tussen de verschillende schermen. Volgens de case steeg het aantal pageviews met 13 procent en nam de gemiddelde gebruiksduur met 32 procent toe.
Lees de volledige Vodafone-case op https://payloadcms.com/case-studies/vodafone
Mazda: sneller publiceren zonder grip op het merk te verliezen
Mazda New Zealand liep tegen een verouderd CMS aan waarin contentwijzigingen traag en omslachtig waren. Nieuwe blokken vroegen veel ontwikkelwerk en voertuiginformatie moest op meerdere plaatsen handmatig worden bijgehouden. Goose ontwierp de componenten eerst in Figma en vertaalde deze vervolgens naar een gestructureerd model en herbruikbare blokken in Payload.
De marketingafdeling kan daardoor zelfstandig pagina’s en modellen beheren, terwijl het designsysteem duidelijke grenzen stelt aan vorm en opbouw. Via API’s en webhooks wordt informatie uit automotive-systemen direct gesynchroniseerd. Mazda rapporteert een jaarlijkse kostenverlaging van 85 procent en een ontwikkelsnelheid die drie tot vijf keer hoger ligt dan in het voormalige Episerver-platform.
Lees de volledige Mazda-case op https://payloadcms.com/case-studies/mazda
ASICS: één platform voor een wereldwijde community
Het ASICS FrontRunner-programma verbindt meer dan 600 ambassadeurs in 33 landen en 25 talen. Achter die community zit een complex digitaal proces: deelnemers beheren profielen en content, lokale teams werken met meertalige informatie en ieder jaar verwerkt de organisatie meer dan 26.000 aanmeldingen. Een traditioneel CMS bood daarvoor onvoldoende flexibiliteit.
Payload combineert contentbeheer, gebruikersprofielen, lokalisatie en geautomatiseerde workflows binnen één omgeving. Ambassadeurs kunnen meer zelfstandig werken en medewerkers besteden minder tijd aan administratieve handelingen. Volgens de case daalde het benodigde ontwikkelbudget met 40 procent en verbeterden de prestaties van de website eveneens met 40 procent.
Lees de volledige ASICS-case op https://payloadcms.com/case-studies/asics
Sonos: campagnes, winkeldata en privacy in één platform
Sonos Europe had voor Duitse campagnes meer nodig dan een eenvoudige landingspagina. Het platform moest regelmatig kunnen veranderen, een dynamische winkelzoeker bevatten en inzicht bieden zonder afhankelijk te zijn van cookies. Payload en Next.js vormden samen de basis waarop .NFQ deze verschillende functies binnen één beheersbare omgeving kon samenbrengen.
Bestaande React-componenten konden opnieuw worden gebruikt en marketeers beheren zelfstandig campagnes en winkelgegevens. Payload levert daarnaast de authenticatie, collecties, drafts en live preview waarop het maatwerkdashboard en de store finder voortbouwen. Sonos rapporteert 75 procent tijdsbesparing bij campagnewissels en 25 procent lagere kosten dan bij andere onderzochte CMS-oplossingen.
Lees de volledige Sonos-case op https://payloadcms.com/case-studies/sonos
Wat is Payload CMS precies?
Payload wordt meestal omschreven als een headless CMS. Dat klopt, maar doet het platform eigenlijk tekort.
Payload is een open-source CMS en applicatieframework dat volledig is ontwikkeld met TypeScript en nauw aansluit op Next.js. Op basis van een configuratie in code genereert Payload onder andere een beheeromgeving, databasestructuur, authenticatie, toegangscontrole en verschillende API’s. Ook functies voor mediabeheer, beeldbewerking, versiebeheer en live preview kunnen binnen dezelfde omgeving worden ingericht.
Een ontwikkelteam krijgt daarmee niet alleen een CMS, maar een technische basis waarop websites, portals, webshops, intranetten en andere digitale toepassingen kunnen worden gebouwd. De organisatie bepaalt zelf welke content, data, gebruikers en processen worden beheerd en hoe deze onderdelen met elkaar samenhangen.
Payload is uitgebracht onder de MIT-licentie. De software mag daardoor kosteloos worden gebruikt en aangepast, ook voor commerciële en bedrijfskritische toepassingen. Organisaties kunnen Payload zelf hosten en houden de controle over de eigen database, code en bestanden.
Dat is een ander uitgangspunt dan bij veel commerciële headless CMS-platformen. Daar huur je toegang tot een externe dienst en betaal je vaak op basis van gebruikers, omgevingen, talen, dataverkeer of API-verzoeken. Bij Payload investeer je in een eigen oplossing die op de organisatie en haar processen kan worden afgestemd.
Dat betekent niet dat een professioneel Payload-platform gratis is. Ontwerp, ontwikkeling, hosting, beveiliging en onderhoud blijven nodig. Het verschil is dat de investering vooral terechtkomt in de eigen oplossing en niet in een steeds groter abonnement op het platform van iemand anders.
Waarom Payload juist nu interessant is
De manier waarop organisaties digitale producten ontwikkelen, is veranderd. Content wordt niet meer alleen gepubliceerd op een website. Dezelfde informatie moet ook beschikbaar zijn in apps, klantportalen, intranetten, winkelapplicaties, displays, zoekmachines en AI-toepassingen.
Ook de grens tussen een website en een applicatie wordt steeds kleiner. Een moderne website bevat vaak formulieren, gebruikersaccounts, dashboards, productconfiguratoren, zoekfuncties en koppelingen met interne systemen. Een traditioneel CMS kan hiervoor worden uitgebreid, maar iedere uitbreiding voegt vaak weer een nieuwe plugin, leverancier of technische laag toe.
Een commercieel headless CMS lost een deel van dat probleem op. Content kan via API’s worden aangeboden en de frontend kan vrij worden ontwikkeld. De organisatie blijft echter afhankelijk van de technische en commerciële kaders van de leverancier.
Payload probeert deze twee werelden te combineren. Het biedt de vrijheid van maatwerksoftware, maar genereert tegelijkertijd veel onderdelen die anders opnieuw gebouwd moeten worden. Denk aan een beheeromgeving, API’s, authenticatie, gebruikersrechten, mediabeheer en versiebeheer.
Daardoor kan Payload compact worden ingezet als CMS achter één website, maar ook uitgroeien tot een centrale content- en datalaag onder een groter digitaal landschap.
Het managementperspectief: meer grip op het digitale landschap
Voor het management is een CMS-keuze zelden alleen technisch. De keuze heeft invloed op de snelheid waarmee de organisatie kan veranderen, de afhankelijkheid van leveranciers en de grip op data en bedrijfsprocessen.
Een belangrijk voordeel van Payload is dat de organisatie eigenaar blijft van de implementatie. De code, database en bestanden kunnen op zelfgekozen infrastructuur worden geplaatst. Daardoor kan een organisatie van hostingpartij of ontwikkelpartner wisselen zonder eerst een volledig platform te hoeven verlaten.
Microsoft noemt die onafhankelijkheid expliciet als een reden om voor Payload te kiezen. Voor het contentplatform rond Microsoft Designer moest kritieke contentinfrastructuur op eigen infrastructuur kunnen draaien. Data-eigenaarschap en het voorkomen van vendor lock-in waren daarbij belangrijke voorwaarden.
Die onafhankelijkheid is niet alleen relevant wanneer een samenwerking misloopt. Het is vooral een vorm van risicobeheersing. Een prijsverhoging, strategiewijziging of productbeslissing van een SaaS-leverancier heeft minder directe invloed op de continuïteit van het platform.
Daarnaast kan Payload veel nauwkeuriger op de organisatie worden afgestemd dan een generiek CMS. Contentstructuren, rollen, rechten en workflows worden in code vastgelegd. Een internationale producent kan andere goedkeuringsprocessen nodig hebben dan een onderwijsinstelling, verzekeraar of zorgorganisatie. Payload hoeft deze organisaties niet in hetzelfde standaardproces te dwingen.
Daarmee verschuift ook de rol van het CMS. Het platform wordt niet alleen gebruikt om webpagina’s te beheren, maar kan eveneens gebruikers, documenten, locaties, producten, aanvragen en andere bedrijfsinformatie bevatten. Dezelfde gegevens kunnen vervolgens beschikbaar worden gemaakt aan de website, een intranet, een app of een klantportaal.
Voor het management betekent dit dat niet voor ieder nieuw initiatief automatisch een nieuw systeem hoeft te worden aangeschaft. Een nieuwe digitale dienst kan voortbouwen op de contentstructuren, gebruikersrechten en koppelingen die al aanwezig zijn.
Het financiële perspectief: minder licenties en minder dubbel werk
Het financiële voordeel van open source wordt soms te eenvoudig voorgesteld. Geen licentiekosten betekent niet dat er geen kosten zijn. Een goed Payload-platform vraagt om ervaren ontwikkelaars, betrouwbare hosting, beveiliging en structureel onderhoud.
De winst zit vooral in de manier waarop de kosten zich op langere termijn ontwikkelen.
De open-source versie van Payload kan zonder licentiekosten worden gebruikt en zelf worden gehost. De organisatie betaalt daardoor niet automatisch meer wanneer het aantal contenttypen, gebruikers, websites of API-verzoeken groeit. Voor aanvullende ondersteuning en bepaalde enterprisefunctionaliteiten bestaan wel betaalde diensten, maar deze zijn geen voorwaarde om eigenaar te blijven van de basis van het platform.
Daarnaast genereert Payload op basis van de configuratie automatisch een beheeromgeving en verschillende API’s. Developers hoeven daardoor niet voor iedere nieuwe toepassing opnieuw een compleet beheersysteem te bouwen. Omdat Payload direct binnen een Next.js-applicatie kan worden geplaatst, kunnen frontend, backend en contentbeheer bovendien nauw met elkaar samenwerken.
Dat bespaart niet alleen tijd bij de eerste ontwikkeling. Een kleiner aantal systemen betekent meestal ook minder koppelingen, minder leveranciers, minder contracten en minder afzonderlijke beveiligings- en beheerprocessen.
Dit wordt vooral zichtbaar wanneer Payload niet alleen het CMS vervangt, maar ook een deel van de functionaliteit van een DAM, intranetbackend of afzonderlijke applicatie overneemt. Veel organisaties betalen nu voor een los CMS en een los DAM, waarna opnieuw moet worden geïnvesteerd in een koppeling tussen beide systemen. Iedere wijziging aan één van de platformen kan vervolgens gevolgen hebben voor de integratie.
Wanneer content en digitale bestanden binnen Payload worden beheerd, kan die tussenlaag grotendeels verdwijnen. Afbeeldingen, documenten en video’s kunnen direct worden gekoppeld aan producten, campagnes, pagina’s of gebruikers. Dezelfde informatie kan vervolgens via API’s in meerdere kanalen worden gebruikt.
De praktijkvoorbeelden van Payload laten zien waar de financiële winst kan ontstaan. Mazda New Zealand rapporteert een jaarlijkse kostenverlaging van 85 procent na de overstap naar Payload. Ontwikkelingen die in het vorige platform vier tot zes weken kostten, konden volgens de case binnen één tot twee weken worden uitgevoerd.
ASICS rapporteert een budgetverlaging van 40 procent door een efficiëntere ontwikkeling. Sonos Europe noemt een kostenverlaging van 25 procent ten opzichte van andere onderzochte CMS-oplossingen en een tijdsbesparing van 75 procent bij het wisselen van campagnes.
Dit zijn resultaten van specifieke implementaties en dus geen garantie voor ieder project. Ze laten wel zien dat de financiële waarde niet alleen in een lagere licentie zit. De grootste winst ontstaat vaak door sneller te kunnen ontwikkelen, componenten opnieuw te gebruiken en het aantal afzonderlijke systemen te verminderen.
Het ICT-perspectief: één technische basis die kan meegroeien
Payload is duidelijk ontwikkeld vanuit het perspectief van developers. Dat is waarschijnlijk een van de belangrijkste redenen waarom het platform zo snel wordt opgepakt.
Veel traditionele CMS-platformen hebben in de loop der jaren een eigen technische wereld opgebouwd. Developers moeten werken met platformspecifieke templates, plugins en uitbreidingsmechanismen. Payload sluit juist aan op de bestaande JavaScript- en TypeScript-wereld.
De volledige configuratie van het platform wordt vastgelegd in code. Collecties, velden, gebruikersrollen, rechten en koppelingen kunnen daardoor via Git worden beheerd, gereviewd, getest en via CI/CD worden uitgerold. De inrichting van het CMS is niet alleen zichtbaar in een productieomgeving, maar reproduceerbaar vanuit de codebase.
Op basis van deze configuratie genereert Payload automatisch een beheeromgeving en REST-, GraphQL- en lokale API’s. Een contenttype dat in Payload wordt toegevoegd, is daardoor direct beschikbaar voor zowel redacteuren als andere applicaties.
Payload kan binnen dezelfde Next.js-applicatie draaien als de frontend, maar hoeft niet op die manier te worden gebruikt. De API’s kunnen ook content aanbieden aan andere websites, mobiele apps, intranetten en externe systemen. Daardoor kan per toepassing worden bepaald of een compacte of juist volledig ontkoppelde architectuur het meest logisch is.
Ook de infrastructuur blijft vrij te kiezen. Payload ondersteunt onder andere PostgreSQL, MongoDB en SQLite en kan worden geplaatst op iedere geschikte omgeving waarop Next.js kan draaien. Voor bestanden zijn opslagadapters beschikbaar voor bijvoorbeeld Amazon S3, Google Cloud Storage en Vercel Blob Storage.
Payload bevat daarnaast authenticatie en gedetailleerde toegangscontrole. Rechten kunnen worden toegepast op collecties, documenten, handelingen en individuele velden. Aanvullende enterprisevoorzieningen zoals SSO kunnen worden gekoppeld aan SAML- en OAuth 2.0-identiteitsproviders.
Die vrijheid brengt ook verantwoordelijkheid met zich mee. Een organisatie die zelf de code, data en infrastructuur beheert, moet ook zelf zorgen voor updates, monitoring, back-ups en beveiliging. Open source vermindert de afhankelijkheid van een platformleverancier, maar neemt professioneel beheer niet weg.
Vrijheid zonder onbeheersbare pagina’s
Een developer-first CMS roept al snel de vraag op of redacteuren daar niet de dupe van worden. Bij Payload hoeft dat niet zo te zijn.
De beheeromgeving wordt automatisch opgebouwd aan de hand van de contentstructuur. Developers bepalen welke velden, instructies, relaties en handelingen een redacteur ziet. De interface kan bovendien met eigen React-componenten en schermen worden uitgebreid. Hierdoor kan de beheeromgeving precies aansluiten op het werkproces van de redactie.
Dat is een belangrijk verschil met volledig vrije paginabouwers. Een paginabouwer lijkt redacteuren veel vrijheid te geven, maar leidt in de praktijk vaak tot inconsistente pagina’s. Redacteuren moeten zelf beslissen over kolommen, witruimte, typografie en vormgeving. Na verloop van tijd ontstaat een website waarin iedere pagina net anders is opgebouwd.
Met Payload kan worden gewerkt met vooraf ontworpen contentblokken. De redactie kan bijvoorbeeld kiezen uit een tekstblok, afbeelding, video, quote, formulier of overzicht. Binnen ieder blok worden alleen de instellingen aangeboden die daadwerkelijk nodig zijn. Daardoor blijft de redactie flexibel, terwijl het ontwerp en de technische kwaliteit worden bewaakt.
Bij Mazda werden de onderdelen van het designsysteem eerst in Figma ontworpen en daarna vertaald naar corresponderende blokken in Payload. Dat gaf de marketingafdeling ruimte om zelfstandig pagina’s op te bouwen, zonder dat de visuele samenhang van de website verloren ging.
Payload ondersteunt daarnaast live preview. Redacteuren kunnen de daadwerkelijke frontend binnen de beheeromgeving bekijken en zien wijzigingen direct verschijnen terwijl zij de content aanpassen. Versiebeheer, concepten en automatisch opslaan maken het mogelijk om wijzigingen voor te bereiden en eerdere versies te herstellen.
Ook internationale content kan binnen dezelfde structuur worden beheerd. Payload ondersteunt lokalisatie op veldniveau en de beheeromgeving zelf is beschikbaar in meer dan dertig talen. Dat betekent dat niet iedere tekst of ieder veld verplicht op dezelfde manier hoeft te worden vertaald.
Het vaak onderschatte voordeel: Payload als Digital Asset Management-systeem
Veel grotere organisaties beheren hun afbeeldingen, video’s, presentaties en documenten in een afzonderlijk Digital Asset Management-systeem. Dat DAM wordt vervolgens gekoppeld aan het CMS, intranet en andere applicaties.
Op papier ontstaat daarmee één centrale bibliotheek. In de praktijk levert het ook een nieuw systeem op met eigen gebruikersbeheer, licenties, metadata, workflows en koppelingen. Redacteuren moeten regelmatig wisselen tussen het CMS en het DAM. Technische teams moeten ervoor zorgen dat rechten, bestanden en metadata tussen beide platformen gesynchroniseerd blijven.
Payload kan deze rollen binnen één platform samenbrengen. Het biedt bestandsupload, opslag, mappenstructuren, mediacollecties en de mogelijkheid om eigen metadata aan bestanden toe te voegen. Ook kunnen bestanden worden gekoppeld aan andere gegevens binnen Payload, zoals producten, campagnes, artikelen, medewerkers of locaties.
Een afbeelding is daardoor niet alleen een bestand met een bestandsnaam. Een organisatie kan ook vastleggen wie de eigenaar is, voor welke landen en merken het beeld mag worden gebruikt, wanneer de gebruiksrechten verlopen en welke alternatieve tekst nodig is voor toegankelijkheid. Deze velden zijn volledig aanpasbaar, omdat een mediabestand binnen Payload net als andere content als een gestructureerd document kan worden behandeld.
Payload kan bij het uploaden automatisch verschillende beeldformaten genereren. Ook zijn functies beschikbaar voor bijsnijden en het instellen van een focuspunt, zodat een afbeelding op verschillende schermformaten goed wordt uitgesneden. De bestanden kunnen lokaal worden opgeslagen, maar ook via een opslagadapter in bijvoorbeeld S3 of Google Cloud Storage worden geplaatst.
Rechten kunnen per collectie, document of veld worden ingericht. Een communicatieafdeling kan bijvoorbeeld alle bestanden beheren, terwijl externe partners alleen goedgekeurde materialen mogen bekijken of downloaden. Versiebeheer en auditinformatie kunnen worden gebruikt om wijzigingen te volgen en eerdere versies te herstellen.
De grootste waarde ontstaat echter niet doordat Payload een afzonderlijk DAM nabouwt. De waarde zit juist in de verbinding tussen assets, content en applicaties.
Een campagneafbeelding kan in Payload worden gekoppeld aan de campagne waarvoor deze is gemaakt. De website, het intranet en een winkelapplicatie kunnen vervolgens hetzelfde goedgekeurde bestand gebruiken. Wanneer een nieuwe versie wordt geplaatst of de gebruiksrechten verlopen, hoeft die wijziging niet in verschillende systemen afzonderlijk te worden verwerkt.
Daarmee ontstaat één centrale bron voor zowel content als digitale bestanden. Payload is dan niet het CMS naast het DAM en het intranet, maar de content- en datalaag die deze kanalen met elkaar verbindt.
Voor organisaties met zeer specialistische DAM-eisen kan een afzonderlijk systeem nog steeds logisch zijn. Denk aan complexe licentierechten, grootschalige videobewerking of uitgebreide portals voor wereldwijde mediapartners. De vraag moet daarom niet zijn of Payload ieder gespecialiseerd DAM volledig kan vervangen.
De betere vraag is welke functionaliteit de organisatie werkelijk nodig heeft. Veel organisaties gebruiken slechts een beperkt deel van hun uitgebreide DAM-platform, terwijl zij wel betalen voor het volledige systeem en de koppelingen daaromheen. In die situaties kan Payload een veel compactere en beter geïntegreerde oplossing bieden.
Wat bouwen grote organisaties met Payload?
De cases van Payload laten goed zien dat het platform niet voor één specifiek type website wordt gebruikt. Het wordt vooral gekozen wanneer content moet worden gecombineerd met maatwerk, integraties en specifieke bedrijfsprocessen.
Vodafone gebruikt Payload voor touchscreenapplicaties in winkels. De schermen zijn opgebouwd vanuit een modulair designsysteem in Figma en vertaald naar beheersbare blokken in Payload. Redacteuren kunnen de inhoud aanpassen zonder voor iedere wijziging afhankelijk te zijn van developers. Volgens de case steeg het aantal pageviews met 13 procent en nam de gemiddelde gebruiksduur met 32 procent toe.
Mazda New Zealand beheert met Payload zowel de website als de gegevens over het complete wagenaanbod. Informatie uit automotive-systemen wordt via API’s en webhooks gesynchroniseerd. Daardoor hoeft de marketingafdeling dezelfde voertuiginformatie niet meer handmatig op meerdere plekken bij te houden. De combinatie van een gestructureerd contentmodel en een modulair designsysteem heeft volgens Mazda ook de snelheid en merkconsistentie verbeterd.
ASICS gebruikt Payload voor het wereldwijde FrontRunner-platform. Het platform ondersteunt meer dan 600 ambassadeurs in 33 landen en 25 talen. Naast content en profielen wordt ook het jaarlijkse aanmeldproces met meer dan 26.000 deelnemers via Payload ondersteund.
Sonos Europe gebruikt Payload en Next.js voor een campagneplatform met een winkelzoeker en een privacyvriendelijk dashboard. Marketeers kunnen campagnes en winkelgegevens zelf beheren, terwijl bestaande React-componenten opnieuw konden worden gebruikt.
Microsoft gebruikte Payload voor het contentplatform rond Microsoft Designer. Flexibiliteit, controle over data en de mogelijkheid om het platform op eigen infrastructuur te draaien waren belangrijke redenen voor de keuze.
Deze toepassingen lijken aan de buitenkant weinig op elkaar. Een automotive website, internationale community, winkelapplicatie en campagneplatform zijn verschillende digitale producten. Technisch hebben ze wel dezelfde behoefte: gestructureerde content moet worden gecombineerd met specifieke processen, gebruikers, integraties en interfaces.
Is Payload voor iedere organisatie geschikt?
Payload is geen kant-en-klare websitebouwer. Het biedt een sterke technische basis, maar moet worden ingericht door developers die verstand hebben van TypeScript, Next.js, databases, beveiliging en softwarearchitectuur.
Voor een kleine website met enkele standaardpagina’s kan een eenvoudiger CMS praktischer zijn. Ook wanneer een organisatie helemaal geen verantwoordelijkheid wil dragen voor hosting en technisch beheer, kan een volledig beheerde SaaS-oplossing beter passen.
Payload wordt vooral interessant wanneer een organisatie een website of applicatie op maat nodig heeft, content via meerdere kanalen wil gebruiken of verschillende onderdelen van het digitale landschap wil samenbrengen. Ook complexe rollen, internationale content, maatwerkkoppelingen en een wens om grip te houden op data en code zijn goede redenen om het platform te onderzoeken.
De afweging gaat daarom niet alleen over de vraag welk CMS de meeste functies heeft. Het gaat er vooral om of de organisatie een kant-en-klaar product zoekt of een flexibele basis waarop de komende jaren verder kan worden gebouwd.
Maar Payload is toch overgenomen door Figma?
Op 17 juni 2025 maakte Figma bekend dat het team achter Payload onderdeel werd van Figma. Dat roept begrijpelijkerwijs vragen op. Payload positioneert zich immers nadrukkelijk als open-source alternatief voor gesloten CMS-platformen.
Volgens zowel Payload als Figma blijft het platform open source. Ook de mogelijkheid om Payload zelf te hosten, de betrokkenheid van het bestaande team en de focus op de community blijven behouden. Het belangrijkste verschil is dat het team toegang heeft gekregen tot meer mensen en middelen en Payload verder kan integreren met designsystemen en de producten van Figma.
Voor bestaande gebruikers verandert daarmee niet direct iets. Zij blijven eigenaar van hun eigen implementatie, database en infrastructuur. De bestaande open-source releases blijven onder de MIT-licentie beschikbaar en organisaties kunnen Payload blijven hosten en aanpassen.
Het blijft vanzelfsprekend verstandig om de ontwikkeling kritisch te volgen. Payload maakt nu deel uit van een beursgenoteerd softwarebedrijf met eigen commerciële belangen. De toekomstige prioriteiten zullen daardoor niet alleen door de open-sourcecommunity worden bepaald. Tegelijkertijd maakt juist die combinatie de toekomst van Payload interessant.
Figma en Payload kunnen de manier waarop websites worden gebouwd veranderen
Figma wil al lang niet meer alleen de omgeving zijn waarin een ontwerp wordt gemaakt. Met Figma Make, Figma Sites, Dev Mode en verschillende AI-functies probeert het bedrijf de afstand tussen ontwerp en werkende software kleiner te maken.
Figma Make is inmiddels een prompt-to-app-omgeving waarmee gebruikers functionele prototypes en webapplicaties kunnen genereren. Make Kits kunnen componenten, stijlen, richtlijnen en zelfs npm-packages uit een bestaand designsysteem gebruiken. In 2026 introduceerde Figma daarnaast mogelijkheden om lokale code te bewerken, wijzigingen te bespreken en vanuit Figma een pull request voor te bereiden.
Daarmee komt Figma steeds dichter bij de code. Payload lost ondertussen precies het deel op waar veel gegenereerde websites en prototypes nog tekortschieten: de backend.
Een professioneel digitaal platform bestaat niet alleen uit schermen en componenten. Er zijn ook een contentmodel, database, gebruikersrechten, bestanden, API’s, workflows en een veilige beheeromgeving nodig. Dat zijn precies de onderdelen die Payload biedt.
Payload en Figma hebben zelf aangegeven dat zij de kloof tussen ontwerp, code en contentbeheer willen verkleinen en designsystemen dieper met Payload willen integreren. Hoe die integratie er precies uit gaat zien, is nog niet volledig bekend. De richting is inmiddels wel duidelijk.
Tot nu toe werd Payload vooral ontdekt door developers die op zoek waren naar een moderner en flexibeler CMS. Door Figma kan straks ook de omgekeerde route ontstaan. Designers, marketeers en productteams kunnen vanuit een ontwerp of prototype bij Payload uitkomen als professionele backend.
Dat kan ervoor zorgen dat het aandeel van Payload veel sneller groeit dan tot nu toe. Niet omdat iedereen zonder technische kennis opeens een bedrijfskritisch platform kan bouwen, maar omdat de stap van idee naar werkende eerste versie aanzienlijk kleiner wordt.
Daarmee kan Payload uitgroeien tot veel meer dan het volgende populaire headless CMS. Het kan de verbindende laag worden tussen ontwerp, content, digitale assets en code.vEn juist daarom zou de echte groei van Payload nog weleens moeten beginnen.
