Enterprise headless CMS portals

Portals with a real user base

These are content portals I build and maintain for an enterprise client's teams and partners across EMEA, serving over 2,000 users. That scale changes the job. A marketing site can tolerate a rough edge; a portal that people rely on for their day-to-day work cannot, and every architectural decision has to assume the content will outlive any single design.

Headless Craft CMS with a Vue front end

The architecture is Craft CMS running headless, exposing content over GraphQL to a Vue 3 front end. Splitting it this way earns its complexity here: editors get Craft's mature authoring experience, while the front end is free to behave like an application rather than a themed CMS. On the state-heavy portal, Pinia manages client-side state. The trade-off with headless is that you own the glue, so the boundary between CMS and front end, the shape of the GraphQL queries, and the auth handshake all become your problem rather than the platform's.

Authentication and custom modules

These portals are not public. Users sign in through the client's identity provider using OpenID Connect single sign-on, with JWT tokens handling the session between the Vue front end and Craft. None of that ships in a box, so I wrote custom Craft modules to handle it: a module integrating the client's SSO login flow, and further modules for portal-specific data services. Writing Craft plugins and modules, rather than just templates, is where most of the backend engineering on these projects lives.

Leading the Craft 4 to 5 migration

I led the migration of these portals from Craft 4 to Craft 5. On paper that is a version bump; in practice it means auditing every plugin and custom module for compatibility, rebuilding what no longer works, and doing it on live products where editors are working and users are signing in daily. The migration shipped, and the portals now run on Craft 5 with the SSO, JWT and custom module stack intact.

What this work demonstrates

This is long-haul work rather than a launch-and-leave project: the same systems, maintained and upgraded across major versions, with real users on them the whole time. I was the lead developer on these portals within a two-person team, which meant the architecture calls, the client-facing communication and the migration plan were mine to own, with senior support to draw on rather than defer to. Account managers and the creative team came to me for status and blockers because I made those updates a habit rather than an interruption. It also involves the unglamorous parts of platform ownership, from working through requirements with account managers to keeping local environments reproducible with Docker-based tooling so the next developer can pick the project up. If you need someone who can be handed an authenticated, content-heavy platform and keep it moving without breaking it, this is the closest thing I have to proof.