Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Implementing Anonymous Founder Marketing: Removing Personal Identity from Public-Facing Assets

This session focused on a critical business requirement: removing the founder's personal name from all public-facing marketing materials while maintaining brand cohesion. The directive was firm—"I'm not going to deal with the criticism that comes with having my name in public"—which meant a complete sweep of outward-facing assets, automated tooling updates, and infrastructure changes to enforce this policy going forward.

The Problem: Name Exposure Across Multiple Systems

During the previous session, we discovered that "C.B. Ladd, owner of JADA" appeared in marketing emails (card t-f4b3c880), demo sites, progress dashboards, and various automated tools. This wasn't a single file problem—it was systemic. The name appeared in:

  • Email templates in S3 (SDCC hotel outreach campaign)
  • HTML demos at dangerouscentaur.com sites
  • Progress tracking dashboards
  • Google Apps Script files (CrewDispatch.gs, FuneralOutreach.gs, CrewScheduler.gs)
  • Python tooling in /tools/ directory
  • LaunchAgent configurations for scheduled campaigns

The challenge: fixing these assets across multiple platforms (AWS S3, CloudFront, GitHub repos, Google Apps Script) while ensuring the policy stays enforced in future development.

Technical Implementation: A Multi-Layer Cleanup

Email Template Sanitization

The primary offender was the SDCC hotel outreach email campaign stored in S3. The email preview lived at s3://[bucket]/sdcc-hotel-outreach-2026.html with CloudFront distribution serving it. Rather than manually editing, we:

  1. Downloaded the original HTML from S3
  2. Replaced founder name references with "JADA Team" and "Queen of San Diego leadership"
  3. Verified email boat image URLs remained intact (both returned 200 responses—critical for campaign success)
  4. Re-uploaded the sanitized HTML to the same S3 location
  5. Invalidated the CloudFront distribution cache to force edge locations to serve the updated version

The CloudFront invalidation used the pattern /sdcc-hotel-outreach-2026.html, ensuring immediate propagation across all edge locations without waiting for the TTL to expire.

Demo Site Cleanup

Two dangerouscentaur demo sites needed updates:

  • /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

We performed grep searches to identify all name references, replaced them with appropriate alternatives ("presented by JADA" instead of "by C.B. Ladd"), and deployed the updated files to their S3 locations. The corresponding CloudFront distributions were invalidated to clear cached versions.

Dashboard Refresh

The progress dashboard at /Users/cb/Documents/repos/sites/progress.queenofsandiego.com/index.html also contained founder attribution. This was updated and deployed via the same S3 + CloudFront invalidation pattern.

Google Apps Script Audit

Several Google Apps Script files in the queenofsandiego.com project included hardcoded name references:

  • FuneralOutreach.gs
  • CrewDispatch.gs
  • CrewScheduler.gs
  • rady-shell-events/apps-script-replacement/WorshipRsvp.gs
  • rady-shell-events/apps-script-replacement/ViatorApiFollowUp.gs

These files required manual review because they interact with business logic (email signatures, crew dispatch communications). References were either removed or replaced with generic organizational identifiers.

Tooling Updates

The jada_blast.py script, which handles email campaign execution, required updates to ensure new campaigns wouldn't inadvertently include the founder's name. We examined template references and contact field mappings to ensure the automated tooling enforced the new policy.

Additionally, four LaunchAgent configurations for scheduled SDCC campaigns were created:

  • com.jada.hotel-outreach-initial.plist
  • com.jada.hotel-outreach-followup1.plist
  • com.jada.hotel-outreach-followup2.plist
  • com.jada.hotel-outreach-breakup.plist

These configurations ensure campaigns execute on schedule while referencing the updated (sanitized) email templates.

Infrastructure Decisions and Trade-offs

Why S3 + CloudFront for Email Templates?

Email templates in S3 provide version control and global distribution via CloudFront. The edge caching model means emails generated anywhere on the system fetch the latest template version, reducing latency. CloudFront invalidation is instantaneous—critical for time-sensitive campaigns.

Why Not Database-Stored Templates?

Some systems store email templates in databases. We chose S3 because:

  • Templates are large HTML documents with embedded styling—better suited to object storage
  • CloudFront provides built-in CDN behavior and invalidation without application logic
  • Version history via S3 lifecycle policies
  • Easy integration with deployment pipelines (no database migrations needed)

Grep-Based Audit vs. Centralized Configuration

Rather than storing the "no founder name" policy in a single config file, we chose comprehensive file-by-file audits because:

  • Name references exist in different contexts (email signatures, marketing copy, attribution)
  • Some references require business logic changes, not just string replacement
  • A centralized config would catch future violations only if code explicitly references it
  • Manual audit forced review of each usage and appropriate replacement strategy

Key Technical Decisions

Sanitization Strategy: Rather than removing founder attribution entirely, we replaced it with "JADA Team" or "Queen of San Diego leadership," maintaining organizational identity while removing personal name exposure.

Deployment Pattern: All file updates followed the same pattern: modify in local repo → commit → deploy to S3 → invalidate CloudFront distribution. This ensures consistency and auditability across all asset types.

Verification Before Deployment: Email image URLs were verified to return 200 responses before deployment, ensuring campaigns wouldn't fail due to broken assets.

What's Next: Enforcing the Policy Forward

The immediate cleanup is complete, but preventing future violations requires:

  • Code review guidelines for all public-facing templates and copy
  • Environment variables or config templates that establish "approved attribution" strings
  • Automated linting rules to flag founder name in outward-facing code