A practical case study on selecting and implementing a CMS around a project's actual content and technical requirements, illustrated through a Sanity-backed ecommerce catalogue build.
A CMS should empower non-technical teams to publish and update content. Whether that's products, blog posts, landing pages, or media, the CMS needs to be intuitive, scalable, and match the project's technical architecture — which is a different answer for a marketing site than for a SaaS admin panel.
Businesses commonly run into the same content management issues: needing a developer for simple updates, difficult publishing workflows, limited flexibility for custom content, a poor editor experience, a CMS tightly coupled to the frontend, and inconsistent content across pages. These problems raise maintenance cost and slow down publishing.
Rather than standardizing on one CMS for every project, the choice is scoped per project: a headless, schema-driven CMS for a Next.js application versus a self-hosted, backend-heavy CMS for a platform needing custom collections and role permissions, versus a familiar admin interface for a business that will manage its own content long-term with a small team.
For a catalogue-driven storefront, Sanity was selected over WordPress and Payload for a specific reason: the frontend was already committed to Next.js Server Components, and Sanity's API-driven content delivery let the catalogue stay editable by non-technical staff without coupling the CMS to the rendering layer. The same choice would go differently for a SaaS admin panel needing custom collections and permissions, or a small business site better served by WordPress's plugin ecosystem — the CMS is chosen for the project, not the other way around.
Structured content modeling, a real-time visual studio, and API-driven delivery fit React/Next.js applications that need editor-friendly content without giving up frontend control.
Best fit for projects needing full backend control, custom collections, and role-based permissions — SaaS platforms and internal dashboards more than a marketing storefront.
Best fit for businesses that want a widely-adopted, self-manageable platform with a large plugin ecosystem, rather than a custom React/Next.js frontend.
A CMS was selected based on the project's goals, content complexity, and technical requirements, then implemented with a structured content model and an editorial workflow usable without developer involvement.
For a Next.js/React application, the CMS sits behind an API layer — structured content types delivered via GROQ (Sanity) or REST/GraphQL (Payload) — keeping content management decoupled from presentation so the frontend can change without a CMS migration. For WordPress builds, the platform's own templating and plugin ecosystem carries more of that responsibility directly.
Content types were modeled first — pages, posts, services, projects, team members, testimonials, FAQs, categories, navigation, and site settings — so the structure stays consistent as new content is added, rather than improvised page by page. The CMS interface was then configured for non-technical editors: organized collections, rich text editing, image uploads, draft/publish workflows, validation rules, and reusable content blocks.
Matched CMS choice to the project's content complexity, technical stack, and who will be editing content long-term.
Defined structured content types (pages, posts, services, projects, team members, testimonials, FAQs, categories, navigation, site settings) for consistency across the site.
Set up collections, rich text editing, image uploads, draft/publish workflows, and validation rules for non-technical editors.
Connected the CMS to the frontend via API-driven content fetching, supporting static generation and incremental updates without coupling presentation to the content platform.
Validated content accuracy, API responses, media rendering, navigation consistency, responsive layouts, SEO metadata, editor permissions, and the publishing workflow end to end.
As new content types are needed, they're added to the existing model rather than created as one-off page structures, keeping the content system consistent as the site grows.
HA Web Studio is a web design and development agency, and a CMS is one of the decisions we make deliberately per project, not by default. A Content Management System should let a business update its website — products, blog posts, landing pages, media — without needing a developer for every change, and that means matching the CMS to the project rather than picking one platform for everything.
Businesses commonly run into the same problems: needing a developer for simple content updates, difficult publishing workflows, limited flexibility for custom content, a poor editor experience, a CMS tightly coupled to the frontend, and inconsistent content across pages. These issues raise maintenance cost and slow down publishing.
Sanity CMS — implemented as a headless CMS for React/Next.js applications, with structured content modeling, a real-time visual studio, and API-driven content delivery. Best suited for marketing sites, ecommerce catalogues, blogs, documentation, and portfolios.
Payload CMS — implemented for projects needing full backend control and self-hosted infrastructure: authentication, custom collections, role-based permissions, REST and GraphQL APIs, and TypeScript support. Best suited for SaaS platforms, internal dashboards, and custom business platforms.
WordPress — implemented for businesses that want a familiar, widely-adopted platform: page management, blog publishing, a large plugin ecosystem, and built-in SEO tooling. Best suited for service businesses and content-focused sites that don't need a custom React/Next.js frontend.
The CMS decision matters more before launch than after. A content model structured up front — pages, posts, services, projects, testimonials, FAQs, categories, navigation, site settings — stays consistent as the site grows; retrofitting structure onto years of free-form pages is a much bigger project than modeling it correctly the first time.
Our MS Signature Scents build is a working example of this: a Next.js storefront with Sanity CMS managing the product catalogue and editorial content via GROQ, so a non-technical team can update products without a redeploy, while the checkout and order logic stay in application code where they belong. That same decision — CMS matched to the project, not the other way around — carries into our business website development, website redesign, and ecommerce development work.
The trade-off is real: a headless CMS like Sanity gives frontend flexibility but means building the presentation layer yourself, unlike WordPress's built-in templating. We make that call project by project, based on who's actually going to be editing the content and what the frontend already needs to do.
Share your context and we'll map it to the closest architecture, SEO foundation, or implementation pathway from these case studies — including the trade-offs, not just the outcome.