Fernmark

The Story

The Fernmark website serves two distinct audiences: businesses exploring the licence programme for the first time, and existing licensees managing their participation. Both needed a modern, polished experience — but the existing platform was built on an ageing stack that had become difficult to maintain.

A full rebuild was on the table, but after evaluating the scope and budget with the client, we chose a more pragmatic path: incremental modernisation. We'd redesign and rebuild key pages with modern tooling while leaving untouched pages stable and intact. This let us deliver visible improvements within the budget without risking regressions across the broader site.

At the heart of the project was a less visible but equally important goal — giving the NZ Story Group team the ability to manage website content themselves. The previous setup required developer involvement for routine content updates. We needed an architecture that would make content editing safe, intuitive, and independent of the development team.

Content Architecture

The answer was a headless CMS approach: Drupal as the content backend, Next.js as the frontend. But the real work was in how we structured the content layer.

We designed structured content models in Drupal with tightly constrained fields. Rather than giving editors a blank rich-text canvas — where a misplaced div or pasted formatting could break a layout — every content type was composed of defined, validated fields. Editors couldn't accidentally break the site because the CMS simply didn't offer them the tools to do so.

On top of this, we built a component-based page assembly system. Editors construct pages by selecting from a library of pre-built content blocks — hero sections, feature grids, testimonial cards — each with their own structured fields. The blocks are designed to look right in any combination, so the team can create and update pages with confidence.

How It Connects

The Next.js frontend consumes these structured content models via API, rendering each block type with its own React component. This separation means the editorial team works entirely within Drupal's familiar interface, while the frontend guarantees visual consistency regardless of what content is published.

The Dual Tailwind Strategy

One of the more unusual technical challenges was managing two versions of Tailwind CSS within a single codebase. The redesigned pages needed modern Tailwind features, but dozens of legacy pages — not in scope for the redesign — relied on an older Tailwind version with different class naming and configuration.

A full migration would have meant touching every legacy template to update class names and verify visual parity — work that wasn't in scope or budget, and that carried real regression risk for pages the client hadn't asked us to change.

Instead, we implemented a dual-version strategy: new pages compiled against the modern Tailwind configuration, while legacy pages continued using their existing styles untouched. The build pipeline handled the separation, ensuring both sets of styles were generated and applied correctly without conflicts. This let us ship the redesign on schedule while giving the client a clear, low-risk path to migrate the remaining pages in future phases.