Over the last several weeks, we completed a full transformation of a pharmacy e-commerce operation running on WordPress + WooCommerce.

This was not a typical “optimize the site” project.

It was a complete operating-system rebuild across three layers:

1. Operations and catalog management (Airtable as the source of truth)

2. Engineering and deployment workflow (Cursor → GitHub → WP Engine)

3. Production reliability + compliance UX (performance, security headers, accessibility, stability)

The outcome was a system that is faster, safer, easier to maintain, and most importantly: delegatable. The engineering team stopped being a bottleneck for catalog work, and the catalog stopped being a source of ongoing production risk.

This case study explains what we built, why each decision mattered, and how to replicate the same model for any high-variation e-commerce catalog, especially in regulated industries like pharmacy, wellness, or healthcare.

A Note on Operational Impact: From “Updating Products” to Operating a System

Most teams assume e-commerce issues come from design, theme quality, or marketing.

In regulated, high-variation catalogs, the real cause is almost always the same:
the catalog itself becomes unmanageable, and every change becomes risky.

Before this overhaul, the operation suffered from predictable symptoms:

• Product data lived in CSVs and ad hoc exports

• Product titles were inconsistent and difficult to scale

• Variations were hard to link reliably

• Junior staff could not update the catalog without breaking structure

• Fixes were one-off instead of repeatable

• Production reliability was brittle (errors, broken widgets, regressions)

After the rebuild, the operation became structured:

• Airtable became the operational control plane

• Python scripts became deterministic translators

• WooCommerce became the publishing and rendering layer

• Engineering changes became versioned and reversible

• Performance, security, and accessibility became measurable and enforceable

This wasn’t “cleanup.”
It was designing a system that eliminates recurring work.

What We Built (High-Level Architecture)

The architecture is intentionally simple and scalable:

Airtable (Source of Truth)
↓
Python Sync + Normalization Scripts (Deterministic Layer)
↓
WooCommerce (Deployment Target / Rendering Layer)

WooCommerce is no longer the place where catalog logic lives.
It is the place where products are rendered and sold.

This decoupling is the core reason the operation became scalable.

1) Stabilize Production First: Fix Errors Before Building New Systems

Before reworking data pipelines or improving performance scores, we stabilized production.

The Problem

We were seeing production issues that made the store unreliable:

• 500 errors on certain WooCommerce templates

• functions assuming $product existed in every render context

• schema/meta rendering breaking in partial contexts

• JavaScript errors breaking interactive tools

• optimizations triggering regressions that were hard to isolate

The Fix

We hardened the entire WooCommerce rendering surface:

• never assume $product exists

• validate object existence before method calls

• use guard clauses and graceful fallback rendering

• isolate schema / OG logic so failures don’t crash pages

• prioritize stability over optimization

Result

• product pages stopped crashing

• schema/SEO rendering became resilient

• the site became stable enough to safely automate catalog changes

Lesson: You cannot build automation on top of unstable production.

2) Establish a Real Development Pipeline (Cursor → GitHub → WP Engine)

A system is only maintainable if changes are versioned, reviewed, and reversible.

Before touching catalog structure or introducing automation, we aligned tooling:

• Cursor as the primary dev environment

• GitHub as the source of truth and rollback mechanism

• WP Engine as the deployment target (with Cloudflare/WAF constraints considered)

This mattered because every improvement became:

• trackable

• reproducible

• reversible

In regulated commerce, rollback ability is not optional.

3) Replace CSV Catalog Management With Airtable as the Source of Truth

Why CSV Catalogs Fail

CSV workflows break at scale because they are not a system:

• no strong validation

• no enforceable structure

• high merge conflict risk across team members

• fragile handling of variations

• no operational UX for junior staff

• too easy to introduce hidden inconsistencies

For a pharmacy catalog with hundreds of variations, CSV becomes a liability.

Why Airtable Worked

Airtable solved the real operational problem:

• it is usable by non-technical team members

• it enforces structure through field types, selects, and links

• it supports collaboration without corruption

• it provides an audit trail

• it is API-first

The catalog became something the business could operate daily without engineering.

4) Build a Deterministic Normalization Layer (The “Rules Engine”)

Pharmacy catalogs are messy by nature:

• compound names are inconsistent

• strengths appear inside titles

• forms vary wildly (capsule, cream, solution, troche)

• duplicates appear as new “parents” instead of variations

• legacy entries don’t match new conventions

We solved this by building a deterministic normalization layer.

Core Components

normalizer.py
Responsible for:

• parsing compound names

• extracting strength (mg/g, IU, percentages)

• normalizing forms

• generating canonical titles

• generating stable keys and SEO-safe slugs

catalog_rules.yml
Configuration-driven rules for:

• form mappings

• naming conventions

• size standards

• pricing logic hooks

• grouping behavior

This created one of the most important outcomes of the entire rebuild:

Business rules became explicit.
They stopped living in human memory or scattered scripts.

5) Export Existing WooCommerce Catalog Into Airtable (Cleanly)

We built a clean export pipeline:

• exported 691 variations

• produced structured CSVs for import:

  • 332 parent products

  • 691 variations

But more important than exporting was the normalization added at export-time:

• canonical parent titles (strength removed)

• stable product grouping keys

• consistent slugs

• variation strength keys

• import instructions

This turned a legacy WooCommerce catalog into a dataset the team could manage.

6) Clean, Merge, and De-Duplicate the Catalog

The Problem

The catalog contained structural issues:

• strength embedded in parent titles

• multiple parents created for the same compound/form

• orphaned variations that didn’t map reliably

• inconsistent grouping behavior

The Solution

We standardized naming:

• Before: Anastrozole 0.15 mg — Capsule

• After: Anastrozole — Capsule

We merged duplicates using deterministic scripts:

• identified 279 duplicate parent products

• merged variations under canonical parents

• preserved pricing + attributes

This wasn’t just cleanup — it was creating an enforceable catalog structure.

7) Link Variations to Parents Reliably (Where Most Migrations Fail)

Variation linking is the failure point in most catalog migrations.

We implemented multi-layer matching:

• exact parent key matches

• compound + form match

• base compound extraction

• fallback matching for edge cases

Scripts created included:

• link-airtable-records.py

• fix-product-titles-and-variants.py

• link-orphaned-variations.py

• create-parent-from-orphaned.py

Result:

• all 691 variations correctly linked

• only 8 true orphans identified and resolved

8) Enrich the Catalog With Clinical Fields (Ingredients + Directions)

This step mattered for pharmacy because product content is not just marketing.

We built enrichment scripts to extract clinical fields from WooCommerce and store them in Airtable:

• active ingredients

• inactive ingredients

• prescriber directions

Outcome:

• 689 / 691 variations enriched (99.7%)

• Airtable became the location where product truth lives (including clinical metadata)

9) Performance, Accessibility, and Security Improvements (Publishing Layer Hardening)

Once the operational architecture was stable, we hardened the publishing layer (WordPress/WooCommerce) so it meets production expectations.

What Changed

• security headers implemented at the edge (CSP, HSTS, etc.)

• image delivery optimized (responsive images, explicit dimensions)

• layout shift eliminated (CLS = 0)

• accessibility issues corrected (labels/IDs/names, contrast, descriptive links)

• render-blocking resources reduced responsibly

• console errors eliminated

This work was not separate from Airtable.
It ensured that once the catalog pipeline scales, the front-end experience remains stable.

Final Results

Operational System (Catalog)

• Airtable source of truth implemented

• deterministic scripts for export, normalization, and import

• duplicates resolved

• orphans resolved

• clinical enrichment in-place

• junior team can manage the catalog without engineering

Production System (Publishing)

• stable templates hardened against null contexts

• security headers deployed correctly at edge

• performance scores improved dramatically

• accessibility brought toward WCAG standards

• regressions controlled through versioned workflow

Closing Thought

This was not just “catalog work” and not just “performance optimization.”

It was a full operating model redesign:

• Airtable became the operational brain

• Python scripts became deterministic translators

• WooCommerce became a publishing surface

• engineering became a controlled pipeline, not firefighting

• the team gained leverage instead of accumulating maintenance debt

If you operate a high-variation catalog in a regulated industry and feel like every product update creates risk, this is the approach that fixes it.