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 like this one.
Last updated
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
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) 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), serving content over GraphQL to a Next.js 16 (case study) 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). The Statamic repository was created in July 2026 (case study), 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)
More client work
Tourism & Hospitality
NRMA Parks & Resorts: WordPress to Contentful Migration
Public interest / open government data and AI agents
publicdata.au: Versioned Government Open Data, Ready for AI Agents