The Client
A Canadian natural health products company operates three core consumer brands, plus a wide network of campaign microsites, product education pages, blogs, recipes, and gated B2B resources built up around them. The flagship brand's ecommerce site is the company's most important digital property. Years of organic growth had spread the wider ecosystem across separate WordPress installations, subdomains, and outside platforms, with no shared architecture, taxonomy, or workflow connecting any of it. A WordPress security incident had already left the internal team unable to fully troubleshoot or control the platform underneath their own websites.
What Was Broken
Marketing needed to make routine changes on its own: copy edits, image swaps, landing pages, campaign updates. WordPress permissions offered no safe middle ground for that. Enough access to fix a typo was also enough access to break a template, so nearly every small change routed back through a developer regardless of how minor it was. The real editorial process lived outside the CMS entirely, running through Asana, Slack, and email for approvals, missing assets, and regulatory checks. Product details — ingredients, claims, imagery — were scattered across product pages, blogs, recipes, and campaign content with no reliable way to see every place a given product or claim appeared. When a regulatory question came up, the team searched the site by hand to find what needed a second look. Some gated B2B resources, meant to require authentication, ultimately linked out to Google Drive files that anyone holding the link could open.
What We Actually Found
The engagement began as a request to introduce Payload as a CMS. The discovery work that followed surfaced a structural problem reaching well beyond content management. Marketing's real need was structured, secure autonomy: genuine ownership over the content types they create and update constantly, inside boundaries that keep templates, product data, and compliance-sensitive functionality out of reach. That boundary had never been drawn cleanly in the existing setup, so the WordPress permission model applied one blunt setting to a problem that actually needed several different boundaries, one per content type and one per role.
The scope, originally sold as a two-week Payload discovery sprint meant to produce a foundation document, expanded during the work itself into a full architecture and operating-model package spanning roughly 40 areas: multi-tenancy across the company's three brands, English/French routing and translation workflow, editorial approval logic, product traceability, asset governance, and a complete migration risk assessment covering the entire WordPress estate.
What We Changed
One shared foundation, not three CMS instances
A single multi-tenant Payload backend now supports the flagship brand, with the architecture already built to bring the two additional brands onto the same foundation. A user can hold different access on different brands under one login, and the admin interface itself is tenant-aware, so editors see which brand they're working in rather than guessing.
Controlled autonomy instead of a page builder
Core layouts — the homepage hero, global navigation, the primary product and blog templates — stay locked in code. Marketing gets safe, deliberate configuration on top of that: editable banners, selectable featured products, and structured templates for the content types that recur constantly (campaign pages, recipes, events, giveaways), each built once instead of reconstructed from scratch by a developer every time marketing needs a new one.
An editorial workflow that actually lives in the CMS
Draft, review, approval, and publish states are now built into Payload directly, replacing the informal chain of Asana tickets, Slack messages, and email chains. The approval logic itself got more sophisticated once real cases were mapped: some content needs one marketing reviewer and one regulatory reviewer together, some needs any one of several eligible approvers, and the rules differ by content type. Payload's built-in document locking also addresses the stale-lock, concurrent-editing conflicts that had been causing problems in the client's other internal systems.
A migration built on reconciled evidence
The team crawled the entire live site and cross-referenced it against the WordPress database, the sitemap, and Search Console data, producing a working inventory of roughly 3,700 URLs. That reconciliation caught a locale-pairing defect that would have matched English and French page translations incorrectly during migration, a mistake that would have caused real SEO damage after launch. The sitemap alone turned out to hold outdated and duplicate entries alongside URLs already returning 404s, so the accurate migration register came from checking four separate data sources against each other rather than trusting any single one.
Product data with one clear source of truth
The client's internal product-information system remains the sole authority for product data. The first implementation queried that system's data live, at request time, for every page. Midway through the build, the client's implementation partner flagged a problem with that approach: it would make website queries slower and complicate the ecommerce plans already underway for a third brand. The architecture changed to a synchronized Payload collection, kept current from the source system automatically, while leaving ownership of the underlying product truth exactly where it started.
Internal team included, not sidelined
The client's own developers and outsourced implementation partner stayed directly involved throughout, rather than receiving a finished system after the fact. Weekly technical sessions, shared repository access, a running staging environment, and documented architecture decisions gave the internal team full visibility into how the platform was being built. That visibility is what surfaced the product-data flaw in the first place: a senior architect on the client's implementation partner reviewed the working system, identified the weakness in the live-query approach, and the design changed because of it. The client kept delivery ownership with the outside team while making sure its own people understood every decision well enough to maintain the system afterward.
The Opportunity That Changed the Engagement
The discovery phase was scoped and priced as a two-week sprint, with the client explicitly free to walk away at the end of it. What that sprint produced was a documented picture of how deep the underlying problem actually ran: three brands, a dozen recurring content types, and years of ungoverned growth, sitting on a platform the client had already lost confidence in. The client reviewed that finding, raised no fundamental objection to the proposed architecture, and signed off within days. A discovery engagement priced at €7,500 opened a roadmap the client sized at €51,000 across website and asset-management work, and the client authorized the first €18,000 implementation phase immediately rather than waiting to see a smaller piece proven out first.
What This Means for Similar Companies
Any company running multiple consumer brands on a CMS it no longer fully trusts will recognize this pattern before it becomes acute: marketing waiting on developers for routine changes, product information nobody can reliably trace across the site, and a migration everyone privately dreads because no one can say with confidence what would break if it started. The most valuable first move is scoping discovery work that maps exactly where that risk sits and what the organization actually needs to be able to do safely, before a single page gets rebuilt. That work is measured in weeks and costs a fraction of finding the same problems mid-migration, with a launch date already public and no room left to fix the architecture underneath it.
The signal worth paying attention to is what happens after the discovery document lands. A report that gets filed away answered a question nobody urgently needed answered. A report that gets signed off within days and converted into a funded implementation phase, the way this one was, means the discovery found something the organization already knew it was sitting on and needed a credible plan to address. That conversion rate, from diagnosis to funded action, is a better predictor of whether the underlying architecture problem is real than any amount of pre-engagement scoping conversation can be.