How Recurrent Streamlines Its Tech Stack For Growth

In partnership with

How Recurrent Streamlines Its Tech Stack for Growth

Brian Morrissey

May 22, 2025 — 9 min read

With a portfolio of brands acquired on different systems, Recurrent’s product team was spending more time maintaining platforms than shipping products. In The Rebooting’s recent online forum, Aaron Segal, principal product manager at Recurrent, joined James Giroux, technical account manager at WordPress VIP, to walk through how Recurrent approached a multi-brand CMS migration, what they learned from it, and how it’s shaping their AI and product roadmap moving forward.

1. You don’t need a special CMS. You need a scalable one.

When Recurrent audited its portfolio, it found six distinct CMS setups across nine brands. There were hybrid builds, headless deployments, and one platform running four CMSs at once. It wasn’t just messy. It was unsustainable. Teams were recreating the same functionality in parallel, which drained engineering bandwidth and limited experimentation. Rather than continuing to build custom tools, Recurrent adopted a modern CMS that could scale across brands, reduce redundancy, and still allow for editorial independence.


“We had to build the same thing six times,” said Segal. “That meant every product idea came with six timelines, six maintenance cycles, and six opportunities to break something. It wasn’t just inefficient. It was paralyzing.”


The shift to WordPress VIP gave Recurrent a unified system that balanced flexibility and reuse. Brands shared the same backend infrastructure while retaining their editorial voice. Instead of reinventing features, teams could plug in proven components and move faster.

Key Takeaway:

  • Recurrent started with six different CMS environments across its brands
  • Moved to a shared WordPress VIP setup that supports reuse without uniformity
  • Editorial teams retained control over voice and design while engineering gained speed

💡WordPress VIP Expert Tip

 “Modern CMS strategy is about adaptability. You want a platform that supports your brand’s growth without boxing you into a rigid way of working. That’s what lets you evolve without rewriting your playbook every six months.” – Giroux

2. A migration will take exactly as long as you let it.

Migrations often stall because of unclear scope and internal hesitation. Recurrent avoided this by scoping tightly, working in parallel tracks, and resisting the urge to customize midstream. The team migrated eight sites in eight months. External partners handled the migration itself, while internal teams focused on feature development and innovation.


“A migration will always expand to fill the space you give it,” said Segal. “You can give it a year, and it’ll take a year. You can give it three years, and it’ll still come down to the final week. We committed to a realistic scope and stuck to it. The goal wasn’t perfection. It was progress.”


Editorial teams had veto power if something wasn’t working. Once the MVP was met, the focus was on shipping and improving after launch—not polishing endlessly before it.

Key Takeaway:

  • Eight brands migrated in eight months with continued feature development during rollout
  • Editorial had early input and final say on launch readiness
  • A clear MVP helped the team avoid scope creep and stay on track

💡WordPress VIP Expert Tip

 “The biggest reason migrations stall is lack of shared ownership. If product leads alone are driving it, it’s always someone else’s problem. Bring in editorial and revenue teams early, and keep the scope defensible.” – Giroux

3. Reuse isn't just a design system. It’s a speed system.

Recurrent built a theme architecture designed for speed. With parent/child themes and a block library, the team reused up to 80 percent of the codebase across brands. This reduced build time, simplified QA, and made redesigns far more efficient. A new homepage for Task & Purpose was completed in two sprints by a single engineer. These improvements didn’t sacrifice editorial flexibility—they preserved it.


“A full homepage redesign took two sprints and one engineer,” said Segal. “That would have taken months before. Now we’re reusing patterns, adjusting spacing and color, and shipping fast. Redesigns are no longer a heavy lift.”


Each completed project contributed to the larger library, making every future build easier. Editorial teams could request design changes or feature enhancements and get them weeks later instead of quarters.

Key Takeaway:

  • Theme inheritance and reusable blocks allowed 80 percent of features to be reused
  • Redesigns that once took months now launch in weeks
  • Modular components gave each brand control without slowing development

💡WordPress VIP Expert Tip

 “Speed isn’t just about code. It’s about reusability. With a modular system, your editorial and product teams stop rebuilding the wheel and start stacking wins.” – Giroux

4. When a story spikes, infrastructure matters more than content.

In March, The War Zone published a scoop on Boeing’s new F-47 fighter jet. Traffic jumped 6x in under an hour. At most publishers, that’s when the site starts to fail. At Recurrent, it held. The infrastructure scaled, the CMS performed, and the product and SEO teams extended the traffic tail through recirculation and optimization.


“Traffic surged, and database usage doubled,” said Segal. “We had over 9,000 concurrents, and everything just worked. In the past, that might’ve broken the site. This time, Editorial focused on the story instead of tech problems.”

Key Takeaway:

  • The War Zone’s story produced a 6x traffic spike with no site issues
  • Product and SEO teams extended traffic longevity through fast follow-ups and recirculation
  • Editorial teams could move quickly without worrying about system performance

💡WordPress VIP Expert Tip

 “The biggest reason migrations stall is lack of shared ownership. If product leads alone are driving it, it’s always someone else’s problem. Bring in editorial and revenue teams early, and keep the scope defensible.” – Giroux

5. AI should accelerate workflows. Not replace them.

Recurrent treats AI as a utility, not a headline. The product team uses it to reduce friction in engineering and editorial workflows. GitHub Copilot increased sprint velocity. Internal tools now assist with alt text, categorization, and image cropping. Nothing gets published without human oversight, but a lot gets done faster.


“We’re not using AI to write articles,” said Segal. “We’re using it to handle the 50 little things that surround the article—image cropping, metadata, SEO. Copilot has helped us close more tickets with fewer bugs. It’s not magic. It’s momentum.”


This approach allows Recurrent to test new tools quickly and pivot as needed. AI is not a strategy. It’s a lever.

Key Takeaway:

  • GitHub Copilot improved engineering output and QA
  • AI is used for backend tasks like tagging and link checking, not writing
  • Human review remains a requirement for all editorial-facing applications

💡WordPress VIP Expert Tip

“The most valuable use of AI today is removing friction. Don’t wait for it to write your homepage. Start with the 20 things slowing down your team and give them tools to move faster.” – Giroux

Lessons learned

The Recurrent migration wasn’t just about consolidating systems. It reset how its product, editorial, and engineering teams collaborated. These lessons are now baked into how they work, and they’re useful for anyone facing similar decisions.


1. Build for adaptability, not just delivery.

You need a system that can evolve. If your CMS can’t change with your business, it’s a liability.

2. Set scope and stick to it.

Every migration is a magnet for new ideas. Define what version 1 looks like, launch it, then improve from there.

3. Editorial buy-in is non-negotiable.

Migration success depends on early and active involvement from the people using the system every day.

4. Reuse creates speed.

Standardized components saved Recurrent hundreds of hours. The more they reuse, the faster they ship.

5. Partnerships free up focus.

External partners managed execution so internal teams could keep building. The result was faster delivery and more momentum.