The engineer's guide to content operations [E-commerce edition]

Written by John Siciliano

Why can some teams launch global campaigns in minutes (👋 Tecovas) while yours is still waiting on a homepage swap?

Hint: It’s not their CMS. It’s their architecture.

The best teams don’t scale by adding headcount or hacking together workflows.

They build systems around their team and operations.

Not a custom CMS, but a stack built on structured content, developer primitives, and programmable workflows.

Fully customizable. Minimal maintenance. Built to scale.

Why now? Delay has real costs.

Commerce teams are creating more content for more surfaces with smaller teams and higher expectations. But most systems were built for publishing, not operations.

AI can't work without structured, queryable content. New surfaces mean more duplication without reuse. Each workaround adds technical debt, and replatforming becomes inevitable.

Sanity gives you the infrastructure to move faster and adapt to whatever comes next. Structured content, programmable workflows, and automation-ready architecture built for scale.

This guide shows the architecture, code snippets, and workflows behind high-velocity, scaling e-commerce teams.

The brands you'll see:

• Tecovas – Western boots and apparel, known for craftsmanship and rapid product drops.
• SKIMS – Kim Kardashian’s shapewear and loungewear brand with a massive global presence.
• Lady Gaga – The artist’s official storefront, featuring exclusive merch and creative campaigns.
• Sanetti – A premium cycling brand built by Sanity to demo complex e-commerce workflows (without NDAs or blurred screenshots).

But first, what’s everyone dealing with right now?

The current state of e‑commerce content ops

E-commerce teams are under pressure to move faster with less.

Customers expect personalized, localized, story-driven experiences across every channel. But most content systems still assume you're shipping static pages, not orchestrating real-time campaigns. AI, automation, and structured content are now table stakes.

Here’s what we’re seeing:

• AI is used to translate entire collections.
• Sales, product drops, and regional promotions still require manual updates across multiple markets, often under tight deadlines.
• Headless CMSes made front ends more flexible, but editorial workflows are still siloed, slow, and hard to scale.
• PDPs are evolving from spec sheets into brand storytelling surfaces with embedded video, longform copy, and dynamic modules tailored by market.
• Teams are expected to support more channels, languages, and surfaces without scaling headcount or adding dev dependencies.

The most forward-looking teams are rethinking how content gets planned, modeled, and delivered, not just how it gets displayed.

Why e‑commerce teams hit a wall

The commerce platform doesn’t matter as much as it used to. They can all sell a product online, whether it’s Shopify, Magento, SFCC, BigCommerce, or Commerce Tools. The real challenge is everything that happens around the product: localized campaigns, seasonal storytelling, personalized promotions, and managing all of it across markets without scaling your team.

Here’s where content operations start to break down:

• Multi-market content is a mess. Launching in five regions means managing five versions of the same content. Every region duplicates efforts.
• Campaigns live in spreadsheets and Slack threads. There’s no single source of truth, so updating a banner means chasing down URLs, translations, and image variants across tools.
• Personalization is talked about more than it’s implemented. Targeting VIP customers or tailoring content by UTM parameters is theoretically possible, but operationally out of reach for most teams.
• Content teams rely too heavily on devs. Even minor updates, like tweaking PDP copy or scheduling a homepage swap, often require an engineer’s time.
• Tech is holding them back. Even with headless stacks and composable platforms, most teams still rely on rigid models, duplicated content, and manual processes that don’t scale.

The shift doesn’t happen because someone wants a shinier CMS. It happens when the cost of doing things the old way gets too high. What starts as fixing one pain point becomes an opportunity to rethink how content moves through your organization—not just how it’s stored or displayed but also how it’s modeled, governed, reused, and orchestrated. I.e., how companies can leverage a Content Operating System.

What is a "Content Operating System"?

You’re already running a content system (even if you didn’t mean to).

It’s the spreadsheets, Slack threads, and last-minute dev requests that hold everything together. Launching a sale means chasing down banners, image variants, and approvals and duplicating those efforts across markets.

A Content Operating System replaces that with actual infrastructure: structured content, developer tooling, and workflows that match how your team operates, not just how content looks but also how it moves.

This guide shows our customers’ architectures in five stages of content operations:

1. Plan and govern – Model complex product data, evolve without rewrites, and enforce smart rules that guide editors without blocking them.
2. Create and manage – Build editing tools that fit your teams’ exact workflows, from full-featured CMSes to single-purpose custom apps.
3. Distribute and automate – Efficiently launch campaigns across languages, regions, and surfaces.
4. Analyze and optimize – Link content variants to conversion data, run experiments, and personalize without ballooning scope.
5. Extend and integrate – Connect to your stack (PIM, ERP, DAM, storefront) with real-time sync and zero infrastructure headaches.

The Content Operating System is built to be shaped. It includes editors, workflows, and data models. Every part is customizable to match how your team works.

This guide shows how engineers at brands like Tecovas, SKIMS, and Lady Gaga moved from managing content to orchestrating it. It’s not about switching CMSes. It’s about building systems that scale with your business.

1. Planning and governing: Architecting your "foundation"

In this section, we'll explore:

• Why "foundation" is in quotes
• The technical features that enable a fluid data model
• How Tecovas models products, colorways, and variants
• How to enable editors to create multi-market campaigns at scale
• Putting precise governance policies in place

The perfect foundation trap

Starting from a blank slate feels like the best opportunity to get it right this time. No more duplicated efforts per market. Let's finally fix our wonky colorways and structure of variants.

Of course, you want to learn from and fix the shortcomings of your current system. However, even if you design the perfect model today, it will slowly calcify as your business evolves (e.g., new product types, seasonal campaigns, unexpected market requirements, etc.).

Most companies are forced into an impossible choice:

• Invest months in an exhaustive content model that tries to anticipate every future need.
• Or build something quick and simple that you'll painfully outgrow within months.

What if your foundation wasn't fixed in concrete but could adapt organically as your needs change? Let's learn how your competition keeps shipping while your developers are stuck maintaining increasingly complex workarounds, and editors spend too much time on manual processes.

Make it work → Make it right → Make it fast

With Sanity, you can follow the classic dev mantra: make it work, make it right, make it fast. Start by shipping something that works. See how it performs. Then refactor and optimize once you understand what’s needed.

These are the technical features unique to Sanity's infrastructure that make this possible:

• Schemaless data store: Without rigid structures, you have the flexibility to add, remove, or modify fields without breaking existing content. If your existing content requires modifications, you can use the Migration API.
• Migration API: Structure changes happen. Not a problem. Use the CLI to create and run migrations (shout out -dry-run flag).
• Marking fields as deprecated: Even small things like marking a field as deprecated when it's at the end of its lifecycle support the evolving data models.
• AI assistance: Because the foundation is in code, you can unleash your favorite agentic coding tool.

This is why “foundation” is in quotes. Sanity doesn’t treat your architecture as a rigid, fixed system. As you learn what works and what doesn't, you can adapt your content system. Thanks, developer tooling.

While the definition of "perfect" will change, let's explore how Tecovas models the trickiest parts of e-commerce.

How Tecovas solved the products, colorways, and variants architecture

E-commerce data is highly relational. So, this begs the question: How do we model our data to enable maximum reuse and flexibility for those edge cases?

Tecovas needed a product model that separated core product information from color-specific details while abstracting away variant complexity. This would enable them to define global product information once and optionally add specific information to colorways, such as care guides.

Before we look at Tecovas, let's look at a simple schema type to ease us into a more complex one: