Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Removing Personal Branding from Marketing Infrastructure: A Multi-System Audit and Deployment Strategy

During a recent development session, we discovered that personal names were embedded in several customer-facing marketing systems across our JADA properties. This post covers the technical approach we used to audit, identify, and systematically remove personal branding from marketing infrastructure while maintaining campaign integrity and avoiding redeployment of unchanged assets.

The Problem: Unintended Personal Branding in Customer-Facing Systems

A routine review of campaign email templates revealed that the phrase "I'm C.B. Ladd, owner of JADA" appeared in email communications within task card t-f4b3c880. This triggered a broader policy decision: personal names should never appear in outward-facing marketing materials. Instead, all customer communications should reference the brand (JADA/Queen of San Diego) and team identity.

The challenge was determining the scope of the problem across a distributed system with multiple repositories, deployment targets, and asset types.

Technical Audit Approach: Recursive Search and File Inventory

We implemented a systematic search strategy across the entire codebase:

  • Primary search target: Search for "C.B. Ladd" and "CB Ladd" variations across all repositories in /Users/cb/Documents/repos/
  • Repository scope:
    • /Users/cb/Documents/repos/tools/ — Automation and blast scripts
    • /Users/cb/Documents/repos/sites/queenofsandiego.com/ — Primary JADA site and Apps Script files
    • /Users/cb/Documents/repos/sites/dangerouscentaur/ — Demo properties and property-specific sites
    • /Users/cb/Documents/repos/sites/progress.queenofsandiego.com/ — Internal progress dashboard
  • File types examined: HTML files, Google Apps Script files (.gs), Python scripts, and deployed S3 assets

We discovered that personal branding appeared in the following categories of files:

  1. Email templates stored in S3 and CloudFront (customer-facing — priority removal)
  2. HTML demo pages for dangerouscentaur.com properties (public-facing — priority removal)
  3. Google Apps Script files for internal automation (CrewDispatch.gs, CrewScheduler.gs) — lower priority as these are internal
  4. Internal progress dashboard (progress.queenofsandiego.com/index.html) — internal only, but cleaned for consistency

Infrastructure and Deployment Architecture

Our marketing infrastructure uses the following stack:

  • Email template distribution: HTML templates stored in S3, served through CloudFront for email preview/verification
  • Demo property sites: Static HTML deployed to S3 buckets with CloudFront distribution in front of specific property domains
  • Primary domain: queenofsandiego.com with subdomains managed via Route53
  • Automation backend: Google Apps Script containers for crew dispatch, scheduling, and outreach campaigns

The key infrastructure resources involved in cleanup:

S3 Buckets:
  - Marketing assets bucket (SDCC email templates)
  - dangerouscentaur demo sites bucket
  - progress.queenofsandiego.com bucket

CloudFront Distributions:
  - SDCC email preview distribution (requires cache invalidation after updates)
  - dangerouscentaur demo distribution
  - progress site distribution

Route53 Configuration:
  - CNAME and A records for property demo domains
  - Alias records pointing to CloudFront distributions

Removal Strategy: Minimize Redeployment, Maximize Safety

Rather than a brute-force find-and-replace across all files, we employed a targeted approach:

  • Step 1: Audit scope — Identify which files had customer-facing exposure vs. internal-only exposure
  • Step 2: Download and inspect — Pull the actual email template HTML from S3 using AWS CLI to examine the exact context of personal branding
  • Step 3: Edit in place — Modify only the customer-facing files; leave internal automation files intact unless they're also exposed
  • Step 4: Redeploy with invalidation — Upload cleaned files back to S3 and issue CloudFront cache invalidation to ensure immediate distribution
  • Step 5: Verification — Re-run audit searches to confirm removal before marking task complete

Example workflow for email template cleanup:

# Download SDCC email template from S3
aws s3 cp s3://[bucket-name]/sdcc-hotel-outreach-2026.html sdcc-hotel-outreach-2026.html

# Edit locally (removed "C.B. Ladd" references, replaced with brand-focused language)
# vim sdcc-hotel-outreach-2026.html

# Upload cleaned version back
aws s3 cp sdcc-hotel-outreach-2026.html s3://[bucket-name]/sdcc-hotel-outreach-2026.html

# Invalidate CloudFront cache for this object
aws cloudfront create-invalidation --distribution-id [DIST_ID] --paths "/sdcc-hotel-outreach-2026.html"

Key Decision: Brand Substitution Language

When removing personal names, we replaced them with variants of:

  • "The JADA team" or "Team JADA"
  • "Queen of San Diego" or "Queen of San Diego Boats"
  • Generic but warm phrasing: "The team at JADA" or "JADA's expert crew"

This maintains brand identity and team personality without introducing individual names into customer communications.

Files Modified During This Session

  • /tmp/sdcc-hotel-outreach-2026.html — Email template (redeployed to S3)
  • /Users/cb/Documents/repos/sites/dangerouscentaur/demos/3028fiftyfirststreet.92105.dangerouscentaur.com/index.html
  • /Users/cb/Documents/repos/sites/dangerouscentaur/demos/demo.dangerouscentaur.com/index.html
  • /Users/cb/Documents/repos/sites/progress.queenofsandiego.com/index.html
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/managercandy/index.html
  • Google Apps Script files (internal-only, lower priority)

Deployment and Cache Strategy

CloudFront cache invalidation was issued for all modified assets to ensure customers see the updated version immediately:

# Pattern for invalidation
aws cloudfront create-invalidation \
  --distribution-id [CLOUDFRONT_DIST_ID] \
  --paths "/sdcc-hotel-outreach-2026.html" "/index.html" "/*"

Using wildcard