The Context

Proactive4Her runs performance marketing campaigns across multiple healthcare verticals—everything from STI testing to PCOS management to alcohol metabolism panels. Each campaign needs its own landing page, optimized for conversion and SEO. The marketing team was constantly requesting new pages: "We need a landing page for our tired-all-the-time campaign by Thursday." "Can we get a PCOS awareness page with testimonials and a booking CTA?" "The alcohol metabolism test needs its own page with custom hero content."

Before our intervention, this process was painful. Each landing page required developer time—around 1.5 to 2 days per page. Worse, these pages were hosted on separate domains, which was killing our domain authority and fragmenting our SEO efforts. The marketing team felt constrained, developers felt overwhelmed, and our organic growth was suffering.

The Problem

The existing workflow looked like this:

1. Marketing team creates a brief and mockups
2. Designer creates assets and layout specifications
3. Developer codes a custom React component with hardcoded content
4. Page gets deployed to a subdomain (because easier DevOps)
5. Marketing team requests changes, cycle repeats

This had several critical issues:

Developer bottleneck: Every page change required engineering time. Marketing couldn't iterate quickly on campaigns or respond to market opportunities.

Domain authority fragmentation: Pages scattered across subdomains meant we weren't building consolidated SEO authority. Our main domain wasn't benefiting from the traffic these campaigns generated.

No content reusability: Common elements like hero sections, testimonial blocks, and CTA components were recreated from scratch each time. Zero component reuse.

Poor SEO foundation: Static meta tags, no structured data, inconsistent URL patterns. Each page was a one-off with minimal search optimization.

The breaking point came when marketing needed to launch three campaigns in a single week. The math didn't work—we simply didn't have 4.5-6 days of developer time to allocate.

The Whiteboard

We needed a system that could:

1. Enable non-technical content creation. Marketing should be able to build pages without touching code.
2. Support component reusability. Common UI patterns (hero sections, testimonials, feature grids) should be drag-and-drop building blocks.
3. Maintain SEO integrity. All pages on the main domain, with proper meta tag management and structured data.
4. Preserve design system consistency. Components should inherit our MUI theme and design tokens automatically.
5. Handle complex content relationships. Healthcare content often links to specific products, categories, and booking flows.

What's our tech stack constraint? We're already using Strapi as our CMS for product content, and our frontend is Next.js with TypeScript. The solution needed to work within this ecosystem.

Initial approach was tempting: build a simple page builder with fixed templates. But healthcare marketing is nuanced—you can't just swap out hero text and call it done. We needed flexible content composition.

The Solution

1. Polymorphic Component Architecture

Logic:

Strapi's component system became our foundation. We created a polymorphic relationship where a LandingPage content type could contain an array of different component types.

Implementation:

// Strapi content structure
LandingPage {
  title: string
  slug: string
  seoData: SEOComponent
  components: [HeroSection | TestimonialGrid | CTABlock | FeatureList]
}

// Each component type has its schema
HeroSection {
  title: string
  subtitle: string
  backgroundImage: Media
  ctaText: string
  ctaLink: string
  sx: JSON // Top-level MUI styling
}

Nuance:

The sx prop was crucial. It let marketing teams apply custom styling (background colors, spacing, responsive breakpoints) without touching CSS. They could make a hero section full-height or adjust padding through the CMS interface.

Resolution:

Built a component registry that mapped Strapi component types to React components. The frontend dynamically rendered whatever component array came from the API.

2. Dynamic Routing and SEO

Logic:

Every landing page needed to live under our main domain with proper SEO metadata and structured data for healthcare content.

Implementation:

// Next.js dynamic route: /landing/[slug].tsx
export async function getStaticPaths() {
  const landingPages = await strapi.find('landing-pages')
  return {
    paths: landingPages.map(page => ({ params: { slug: page.slug }})),
    fallback: 'blocking'
  }
}

export async function getStaticProps({ params }) {
  const page = await strapi.findOne('landing-pages', { slug: params.slug })
  return {
    props: { page },
    revalidate: 60 // ISR for content updates
  }
}

Nuance:

Healthcare content has specific structured data requirements. We needed to automatically generate JSON-LD for medical services, local business information, and FAQ schemas based on the page content.

Resolution:

Created SEO component that analyzed page content and auto-generated appropriate structured data. Marketing team just fills in basic SEO fields, system handles the technical implementation.

3. Component Library Integration

Logic:

Each Strapi component needed to map to a corresponding React component that inherited our design system.

Implementation:

const ComponentMap = {
  'landing-page.hero-section': HeroSection,
  'landing-page.testimonial-grid': TestimonialGrid,
  'landing-page.cta-block': CTABlock,
  'landing-page.feature-list': FeatureList
}

function DynamicComponent({ component }) {
  const Component = ComponentMap[component.__component]
  return <Component {...component} />
}

Nuance:

The sx prop integration was tricky. We needed to merge CMS-provided styling with our theme defaults without breaking responsive behavior or accessibility.

Resolution:

Created a wrapper that validated and sanitized CMS styling input, then merged it with component defaults using MUI's theme system.

4. Content Relationships and Booking Integration

Logic:

Healthcare landing pages often need to link to specific lab tests, booking flows, or product categories. These relationships needed to be manageable through the CMS.

Implementation:

// CTA components could reference products directly
CTABlock {
  title: string
  description: string
  buttonText: string
  linkedProduct: Relation<LabTest> // Direct product relationship
  bookingFlow: Enum<'direct' | 'consultation' | 'package'>
}

Nuance:

Booking flows vary by product type. Some tests require consultations, others are direct-purchase, some are part of care packages. The CTA needed to respect these business rules.

Resolution:

Built intelligent CTA routing that checked product metadata and directed users to the appropriate booking flow automatically.

The Impact

Time to market: Landing page creation dropped from 1.5-2 days to approximately 20 minutes. Marketing team can now respond to trending health topics, seasonal campaigns, and competitive opportunities in real-time.

Domain authority consolidation: All campaign traffic now flows to our main domain. Organic search visibility improved as we stopped diluting link equity across subdomains.

Developer productivity: Engineering team freed up to focus on core product features instead of one-off marketing pages. Reduced context switching and improved sprint predictability.

Content consistency: Reusable components ensure brand consistency across campaigns while allowing customization. No more visual discrepancies between different campaign pages.

SEO performance: Unified domain structure, automatic structured data generation, and consistent internal linking improved search rankings for target healthcare keywords.

What we're particularly proud of is how this system scales. Adding a new component type takes about an hour—create the Strapi schema, build the React component, add it to the registry. Marketing has since requested (and gotten) components for FAQ sections, doctor profiles, and interactive symptom checkers.

The polymorphic approach means we're not locked into predefined templates. Healthcare marketing is complex—different conditions require different content strategies. This system adapts to whatever marketing needs to communicate.

Sometimes the best technical solutions are the ones that completely disappear from the user's perspective. Marketing teams shouldn't think about deployment pipelines or DNS configuration. They should think about conversion rates and patient education.

Though we do occasionally get Slack messages that start with "Can you add a component for..." and honestly? That's exactly what we wanted.