The Inversion Stack

People's sibling blog covered the Inversion — People Inc's strategy to turn media brands into product businesses. MyRecipes with 3.5 million users. The People App with 430,000. InStyle video pulling 45 million views. Nineteen brands, each becoming something you use, not just something you read.

The business logic is sound. Google drove 54% of traffic two years ago; now it's 24%. You can't run a publishing company on a channel that's evaporating. So you build direct relationships — apps, tools, experiences, commerce — that don't depend on search.

But the Inversion isn't a business strategy. It's a platform migration. And the technology decisions behind it are harder than anything the editorial team is facing.

What the CMS Was Built For

People Inc runs a custom Java server-side framework. Freemarker templates. SCSS, ES6, increasingly VueJS on the frontend. Kafka and Pub/Sub for event streaming. A proprietary CMS shared across brands — the legacy of Dotdash's acquisition of Meredith, where two CMSes became one.

The architecture was built for one job: turn editorial content into web pages that rank on Google.

This worked brilliantly for a decade. Dotdash built its reputation on hyper-optimized content pages — fast load times, clean markup, strong Core Web Vitals. The technology served the strategy perfectly because the strategy was simple: rank, monetize, repeat.

Neil Vogel said something revealing about the current architecture: the brands share "only the CMS and ad stack, but nothing else." Each brand is operationally independent. This wasn't a design flaw — it was the design. When your business model is Google traffic → ad impressions, brand independence is an asset. Each brand optimizes its own content, its own SEO, its own editorial voice.

The Inversion breaks this model completely.

What the Inversion Needs

When a brand becomes a product, the CMS stops being the center of the architecture. It becomes one input source among many. MyRecipes doesn't just need recipe pages — it needs user accounts, saved recipe collections, meal planning, grocery lists, push notifications, personalized recommendations. The People App doesn't just need celebrity articles — it needs a content feed, a notification system, an engagement loop that brings people back daily.

Here's what nineteen brand-products actually require:

The CMS covers one row. The Inversion needs ten. That's not a gap you patch — it's a platform you build.

The Three-Layer Model

There's a standard way to think about this migration. Three layers, each with a different owner, different rate of change, and different build-vs-buy calculus.

Layer 1 exists. It's the CMS, the asset management system, the editorial workflow that produces content across 40 brands. The critical change here isn't rebuilding the CMS — it's adding a content API layer on top of it. The CMS continues to do what it does. But instead of content flowing exclusively through Freemarker templates to HTML pages, it also flows through APIs to apps, email systems, recommendation engines, and commerce platforms.

D/Cipher's content graph — the same system that powers their ad targeting — likely already indexes and classifies content in a way that could serve as the backbone of this API layer. This is one of the underappreciated advantages of having built D/Cipher: the content graph is an asset that transcends advertising.

Layer 3 is where each brand builds its specific experience. The People App team (65 people, remember) builds their celebrity news feed and engagement mechanics. The MyRecipes team builds their recipe locker and meal planning. Southern Living builds their commerce integration for sweet tea and architectural plans. These are product teams, not editorial teams, and they need the autonomy to ship at product-company speed.

Layer 2 is where the hard decisions live.

The Platform Boundary Problem

The question that will determine whether the Inversion succeeds or stalls is this: what goes in the shared platform layer?

Put too much in Layer 2 and you create a bottleneck. Nineteen brand teams all waiting for the platform team to build features. Release cycles slow. Brand-specific needs get deprioritized for "platform priorities." The People App team can't ship a notification feature because the shared notification service isn't ready. MyRecipes can't launch grocery list integration because the commerce service doesn't support their use case. This is the classic inner-platform trap — you build a generic system that serves no one well.

Put too little in Layer 2 and you burn money. Nineteen teams each building their own authentication system. Their own recommendation engine. Their own analytics pipeline. Their own push notification infrastructure. You're not running a platform company — you're running nineteen startups that happen to share an office. At ~3,400 employees post-layoffs, People Inc cannot afford this.

Here's how I'd draw the line, based on what we know about People Inc's specific situation:

Shared (Layer 2) — Build Once, Use Nineteen Times

User identity and authentication. This is the clearest shared service. Every brand-product needs user accounts, and crucially, People Inc wants a cross-brand identity. A Food & Wine user is also a potential Allrecipes user. A Travel & Leisure subscriber might buy Southern Living architectural plans. The identity system is the connective tissue of the Inversion. Build it once, with federated brand-specific profiles on top.

Content API. The headless layer over the CMS. Every brand-product needs structured content delivered via API, not HTML. This is the single most important shared investment. Without it, every brand team builds its own content integration, duplicating effort and creating drift between the CMS and the product experience.

Recommendation and personalization engine. The D/Cipher content graph already classifies content across brands. Extending it to power user-facing recommendations is a natural evolution. The algorithms can be shared; the training data and weighting can be brand-specific. This is where the offline embedding approach from D/Cipher pays off — pre-computed content vectors serve both ad targeting and content recommendations.

Analytics and data pipeline. User-level analytics (not just pageview analytics) must be shared infrastructure. The CDP (customer data platform) feeds D/Cipher, feeds recommendations, feeds business reporting. Nineteen separate analytics systems would be a data governance nightmare. Condé Nast's Databricks-on-AWS approach shows what the industry considers table stakes here.

Notification infrastructure. Push, email, SMS — the plumbing is commodity. The content and timing should be brand-specific, but the delivery system is shared.

Bespoke (Layer 3) — Brand Teams Own

The product experience itself. The People App's celebrity news feed is nothing like MyRecipes' meal planning interface. InStyle's video experience has different engagement mechanics than Southern Living's commerce catalog. These are different products. Forcing them into a shared UX framework would kill what makes each brand valuable.

Commerce integration. This is counterintuitive — you might think commerce is shared. But Southern Living sells sweet tea, Food & Wine sells chef knives, Travel & Leisure sells experience packages, The Spruce sells paint. The commerce models are fundamentally different: physical goods, subscriptions, experiences, affiliate, white-label. A shared commerce platform would be a disaster. Better to let each brand integrate with the commerce vendors that fit their model (Shopify, Stripe, Eventbrite, affiliate networks) and share only the payment identity layer.

Events and ticketing. People Inc runs 60+ events annually. But the People's Choice Awards is a completely different production from a Southern Living Home Showcase or a Food & Wine festival. Use an events API (Eventbrite, or internal) for registration and ticketing; build the event experience per brand.

The Build-vs-Buy Map

For each shared service, the CTO faces the same question every media CTO faces: build it, buy it, or compose it from managed services?

The pattern: build where you have proprietary advantage (content API over your own CMS, recommendations from your own content graph), buy where the capability is commodity (identity, notifications), compose where you have partial infrastructure (analytics pipeline exists via Kafka, needs a CDP layer on top).

The CMS-to-API Transformation

The single most consequential technical decision is how to add the content API layer. The CMS doesn't need to be replaced — it needs to be wrapped.

The headless CMS market is booming — projected from $816 million to $3.9 billion in a year. But People Inc shouldn't buy a headless CMS. They should add a headless layer to their existing CMS. Their proprietary CMS already holds the content, the editorial workflows, the brand-specific publishing rules. Migrating to Contentful or Strapi would cost years and break existing operations. Adding a GraphQL or REST API that exposes the same content to new consumers is faster, cheaper, and lower risk.

This is the approach that companies like The New York Times took — they didn't replace their CMS. They built a content API (developer.nytimes.com) that serves the same content to their website, their apps, their newsletters, and third-party consumers. The CMS became a content repository with an API façade, not a page rendering engine.

The Org Chart Problem

Architecture follows organization. If the engineering org isn't restructured to match the three-layer model, the platform won't work.

People Inc is hiring for Java/VueJS full-stack roles in NYC and Bangalore, building "next-generation applications for content publishing and management." Jon Roberts, as Chief Innovation Officer, leads the technology vision. But the Inversion creates a new kind of team structure:

Platform team owns Layer 1 and Layer 2 — the content API, identity service, recommendation engine, analytics pipeline, notification infrastructure. This team ships services, not products. Their users are the brand teams.

Brand product teams own Layer 3 — the People App's 65 people, the MyRecipes team, the InStyle video team. These teams ship products. They build on the platform, not from scratch.

The tension is real. The People App already has 65 staffers. Are they building on shared platform services, or are they building their own infrastructure? If the People App team built their own auth, their own notifications, their own analytics — and the other 18 brand teams have to build theirs too — you've got a scaling disaster. If they're waiting on a platform team that doesn't exist yet, you've got a speed disaster.

The pragmatic path: extract as you go. Let the People App team (the largest, most funded brand team) build what they need. Then extract the reusable parts into shared services for brands 2 through 19. The People App becomes the proving ground for the platform, not the other way around. MyRecipes — already at 3.5 million users across Food & Wine and EatingWell — is brand #2, validating that the extracted services work in a different context.

What This Actually Costs

People Inc has roughly 3,400 employees post-layoffs. Not all of them are engineers — far from it. The engineering team is split between NYC and Bangalore. They're maintaining 40 brand websites, the CMS, the ad stack, D/Cipher, and now building product experiences for 19 brands.

A realistic phasing:

This is a two-and-a-half year journey at minimum. Neil Vogel is betting the company on it. The technology team has to deliver.

The Risk That Matters

The biggest risk isn't technical. It's organizational.

Jon Roberts' instinct — anti-AI-for-content, focused on human-made brands — is right for editorial. But the platform he needs to build is a software engineering challenge, not a publishing challenge. The team that builds a content API, a recommendation engine, and a cross-brand identity system is a platform engineering team. They think in APIs, services, SLAs, and developer experience. They are not the same people who optimize Core Web Vitals on recipe pages.

People Inc needs to decide whether it's a publishing company with some apps, or a product platform company with some magazines. The Inversion says the latter. The engineering org needs to follow.

This is the third in PeopleTech's technology strategy series on People Inc. Previously: The Platform Problem Behind the Rebrand (platform consolidation) and The Inference Tax (D/Cipher ad tech architecture). Business context from people.karaxai.com.