Removing Personal Branding from Customer-Facing Marketing: A Multi-Repository Refactor

```html

This post documents a comprehensive refactor across multiple repositories and deployment pipelines to remove personal branding (C.B. Ladd) from all customer-facing marketing materials while maintaining operational integrity and audit trails for internal systems.

The Problem Statement

During an email campaign audit, we discovered that personal names were embedded throughout customer-facing marketing materials—specifically in HTML email templates, landing pages, and demo sites. While personal branding can be effective, the decision was made to shift to organizational branding (JADA, Queen of San Diego, "the team") to avoid future complications with public perception and attribution.

The challenge: remove these references systematically across:

Email templates in S3 and CloudFront distributions
Landing page demos (dangerouscentaur.com demo sites)
Progress dashboards and public-facing web properties
Google Apps Script files deployed to production
Build tools and blast scripts

Technical Approach: Multi-Phase Audit and Remediation

Phase 1: Inventory and Discovery

We started with a comprehensive grep-based search across all repositories to identify all instances of "C.B. Ladd" in non-internal paths:

find /Users/cb/Documents/repos -type f \
  -not -path "*/\.git/*" \
  -not -path "*internal*" \
  -not -path "*proof*" \
  | xargs grep -l "C\.B\. Ladd" 2>/dev/null

This revealed instances in:

/tmp/sdcc-hotel-outreach-2026.html (email template)
/Users/cb/Documents/repos/sites/dangerouscentaur/demos/ (demo landing pages)
/Users/cb/Documents/repos/sites/progress.queenofsandiego.com/index.html (dashboard)
/Users/cb/Documents/repos/sites/queenofsandiego.com/*.gs (Apps Script files)
/Users/cb/Documents/repos/tools/jada_blast.py (email blast tool)

Phase 2: Email Template Remediation

The SDCC hotel outreach email template contained the phrase "I'm C.B. Ladd, owner of JADA" in the introduction. We replaced this with organizational language: "We're the JADA team at Queen of San Diego" while preserving all HTML structure, styling, and functional elements like boat images (which were verified to be loading correctly from their S3 origins).

After local editing, we uploaded the cleaned template to S3:

aws s3 cp sdcc-hotel-outreach-2026.html \
  s3://[JADA-ASSETS-BUCKET]/email-templates/sdcc-hotel-outreach-2026.html \
  --content-type "text/html"

Then invalidated the CloudFront distribution to ensure edge caches were cleared:

aws cloudfront create-invalidation \
  --distribution-id [SDCC-EMAIL-DIST-ID] \
  --paths "/email-templates/sdcc-hotel-outreach-2026.html"

Phase 3: Demo Site Updates

Two dangerouscentaur demo properties contained personal references in their landing pages:

/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

Both were updated to remove personal attribution and re-uploaded to their respective S3 buckets and CloudFront distributions. The refactor preserved all functional JavaScript, styling, and property showcase elements—only the "about" or introduction sections were modified to reference JADA/Queen of San Diego team branding.

Phase 4: Google Apps Script Auditing

Apps Script files in the queenofsandiego.com repository presented a different challenge: they're deployed to production Google Workspace environments. We audited:

FuneralOutreach.gs (funeral home outreach automation)
CrewDispatch.gs (internal crew scheduling)
CrewScheduler.gs (team scheduling tool)
WorshipRsvp.gs (event RSVP handling)
ViatorApiFollowUp.gs (tour operator integration)

Critical decision: Internal-only Apps Script files were left unchanged. These are not customer-facing—they're operational tools used by the team. Adding personal attribution in internal tools aids debugging and maintains clear ownership. The policy became: remove personal branding from anything a customer, prospect, or public visitor sees; keep it in internal systems for auditability.

Phase 5: Tool and Script Remediation

The jada_blast.py email blast tool is internal infrastructure but is referenced in runbooks and deployment documentation. We updated comment headers and configuration documentation but preserved log entries and internal metadata that reference the original developer.

Infrastructure Decisions and Tradeoffs

Why CloudFront Invalidation Instead of Cache Control Headers

Rather than waiting for TTL-based cache expiration (which could take hours), we immediately invalidated the affected paths. This ensures that within seconds, all edge locations serve the updated content. The tradeoff: CloudFront invalidations incur a small cost per path, but correctness and speed were prioritized over cost in this case.

Preserving Git History

All changes were committed to version control rather than force-pushing or rewriting history. This maintains audit trails and allows any future rollback if needed. The commits clearly document what was changed and why.

Separate Treatment for Customer-Facing vs. Internal

We established a clear policy: customer-facing materials (emails, landing pages, public dashboards) get sanitized of personal branding; internal systems (Apps Script, internal dashboards, tooling) retain attribution for operational clarity. This avoids over-sanitizing and keeps the refactor focused on actual user-visible content.

Validation and Testing

After each deployment:

Verified S3 objects were updated with correct content-type
Confirmed CloudFront distributions invalidated and propagated
Spot-checked deployed HTML files by requesting from CloudFront distribution URLs
Ran final grep sweep to ensure no missed instances in public paths

What's Next

This refactor establishes a foundation for consistent branding governance:

Documentation: Add a branding guidelines document to the wiki specifying approved team names, organizational references, and where personal attribution is acceptable
CI/CD Integration: Consider adding a pre-deployment scan in the build pipeline to catch unauthorized personal references before they reach S3
← All posts