--- type: CaseStudy title: "Cultural Institution: Headless CMS Evaluation and Build" description: National Digital built Statamic, Craft CMS and Payload candidates against one brief for a Queensland cultural institution, then built the chosen CMS. resource: https://nationaldigital.com.au/case-studies/cultural-institution-headless-cms/ tags: - headless CMS evaluation - Statamic headless CMS - Payload vs Strapi vs Craft CMS - CMS selection for an organisation - Cultural institution timestamp: "2026-10-31T00:00:00.000Z" language: en-AU publisher: National Digital author: Tara Buckley authorRole: COO reviewedBy: Cameron Young reviewedOn: "2026-10-31" wordCount: 1110 datePublished: "2026-10-31" dateModified: "2026-10-31" canonical: https://nationaldigital.com.au/case-studies/cultural-institution-headless-cms/ --- *Case study · Cultural institution* # A website its own editors keep current, on a headless CMS chosen by building the candidates A Queensland cultural institution is getting a website its editors keep current, with each item classified, approved and attributed. National Digital chose and is building the headless CMS behind it. National Digital evaluates and builds [headless CMS platforms](/headless-cms/) like this one. Written by [Tara Buckley](/about/tara-buckley/), COO Reviewed by [Cameron Young](/about/cameron-young/), CEO, on 31 October 2026 *Last updated 31 October 2026* ## Technologies - Statamic - Laravel - GraphQL - Next.js - Payload - Strapi - Craft CMS - Cloudflare Workers ## At a glance - **Industry:** Cultural institution - **Engagement type:** CMS evaluation and build - **Team:** National Digital engineering team * [Headless CMS](/headless-cms/) * [Technology Selection Advisory](/digital-strategy/technology-selection-advisory/) ## The challenge The client needed a content management system that its own editors could operate through an admin interface, with a classification for each piece of content, an approval step before anything goes public and an attribution registry. A feature list could not show how each candidate would meet those requirements, so the choice needed working builds. ## What we built National Digital built the site against Statamic, Craft CMS and Payload, each reading the same requirements brief and serving the same Next.js front end, and compared what each schema cost in front-end code. A Strapi repository was created and archived without a build. Statamic was chosen and the build has continued there. - A platform-agnostic requirements brief - Candidate builds on Statamic, Craft CMS and Payload - One Next.js front end that each candidate serves - A comparison of what each schema cost in front-end code - The chosen build on Statamic and Laravel - GraphQL queries with generated types - Live Preview for drafts ## The outcome The client chose its CMS from working builds that share one front-end contract, so the comparison shows what each system cost to integrate. The Statamic build has run since July 2026, and the site has not launched at the time of writing. ## Where it went next National Digital continues to build the site on Statamic. Every call to the CMS passes through one adapter on the front end, so a later change of CMS replaces the adapter and leaves the components alone. This case study describes real work delivered by National Digital for a client that is not named. Selected details are summarised for publication. ## About the engagement The client is a cultural institution in Queensland. The engagement covers its public website and the content management system behind it. National Digital evaluated headless CMS candidates for a Queensland cultural institution against one written requirements brief, and is building the chosen system with a Next.js front end ([case study](/case-studies/cultural-institution-headless-cms/)) The study does not name the client, and it will name the client when the client approves. *Key Takeaways* ## What building the candidates side by side showed - **A written requirements brief lets different CMS products be judged on the same questions.** *Critical* — The brief asked for self-hosting, an admin interface, a front end that is separate from the CMS, content and code on separate lifecycles, versioned schema migrations, classification, approval and attribution. - **Each candidate served the same Next.js front end, so the difference between them shows in the front-end code.** *Critical* — Each front-end component carries its own GraphQL fragment and reads the CMS's own data shape. Comparing two candidate branches shows what each schema costs in code, with no mapping layer to hide it. - **Generated types make a wrong comparison against a CMS field fail the build.** *Important* — The Statamic front end generates TypeScript types from the CMS schema. A change to a field in the CMS fails the front-end build and names the file and line that read it. - **Keeping content and code on separate lifecycles lets a deploy ship without touching what editors saved.** *Helpful* — Definitions and blueprints are versioned in Git, while the content that editors save is stored apart from them. A deploy changes the definitions and writes no editor content. The evaluation judged each CMS on a written brief and on a working build that shared one front end. Statamic was chosen, and the build continues on Statamic with a GraphQL API and generated types. ## Questions decision-makers ask about this build ### What did the CMS evaluation test? The requirements brief asked for a self-hosted CMS with a prebuilt admin interface, a front end separate from the CMS, content and code on separate lifecycles, versioned schema migrations, content classification, an approval workflow and an attribution registry. Each candidate was built against that brief. ### Why build candidates instead of comparing feature lists? A feature list says what a CMS offers. A working build shows what its schema costs in front-end code. The candidates shared one front end, so the difference between two branches of that front end was the comparison. ### Which CMS was chosen, and on what stack? Statamic was chosen. The stack is Statamic 6 on Laravel 13 ([case study](/case-studies/cultural-institution-headless-cms/)), serving content over GraphQL to a Next.js 16 ([case study](/case-studies/cultural-institution-headless-cms/)) front end on Cloudflare Workers. ### How long did the evaluation and build take? The Craft CMS, Payload and Strapi repositories were created in August 2026 ([case study](/case-studies/cultural-institution-headless-cms/)). The Statamic repository was created in July 2026 ([case study](/case-studies/cultural-institution-headless-cms/)), and the build continues. The site has not launched at the time of writing. ### What does this change for the client's editors? Editors work in the Statamic control panel. Live Preview shows a draft on the real front end before it is published. ### Can the client change CMS later? The front end reads the CMS through one adapter and validates every response against its own model. A later CMS change replaces the adapter, and the components stay as they are. ### What did National Digital deliver? National Digital evaluated headless CMS candidates for a Queensland cultural institution against one written requirements brief, and is building the chosen system with a Next.js front end ([case study](/case-studies/cultural-institution-headless-cms/)) ## More client work - [NRMA Parks & Resorts: WordPress to Contentful Migration](/case-studies/nrma-parks-and-resorts/) — Tourism & Hospitality - [publicdata.au: Versioned Government Open Data, Ready for AI Agents](/case-studies/publicdata/) — Public interest / open government data and AI agents ## Choosing a headless CMS for your organisation? Tell us what you are building. We will come back within one business day with what we would do first and what it would take. - [Book a call](https://calendly.com/cameron-at-national-digital/discovery) or · [1300 800 855](tel:+611300800855) ## Related **Parent:** - [Real platforms, in production.](/okf/case-studies.md)