Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Deploying a Static Proposal Page with CloudFront Invalidation: The Jada Charter Proposal Workflow

What Was Done

Created and deployed a new static HTML proposal page for a charter service offering at queenofsandiego.com/proposals/jada-charter-proposal-sue.html. The file was generated from scratch, committed to the site repository, and immediately invalidated through CloudFront to ensure cache freshness across all edge locations.

Technical Details: File Structure and Content Generation

The proposal page was written directly to the proposals subdirectory:

/Users/cb/Documents/repos/sites/queenofsandiego.com/proposals/jada-charter-proposal-sue.html

This file location follows the existing site structure. A preliminary filesystem survey confirmed the proposals directory already existed:

ls /Users/cb/Documents/repos/sites/queenofsandiego.com/proposals/

The page contains several structured sections:

  • Pricing Options: Two tiered offerings (Option A: 2-hour Captain Sergio only at $750; Option B: 3-hour full crew at $1,575) presented as radio button choices to reduce decision fatigue
  • Legal Compliance Notice: USCG licensing and EPA/MPRSA ash scattering regulation language, critical for charter operations involving memorial ash scattering services
  • Historical Context: Hollywood-era content (references to Bogart, Bacall, Flynn, Wayne) to establish brand narrative and emotional connection
  • Interactive Form: Q&A submission form at page footer for lead capture

The content structure prioritizes clarity: exactly two pricing options (not four or more) with one explicitly recommended, reducing cognitive load for prospective customers.

Infrastructure: Static Site Hosting and Cache Management

The queenofsandiego.com domain infrastructure uses a static site architecture:

  • Source Repository: /Users/cb/Documents/repos/sites/queenofsandiego.com/ (local development path)
  • Build Script: publish_static_site.sh (examined via cat publish_static_site.sh | head -40)
  • Distribution Method: AWS CloudFront CDN (confirmed via invalidation commands)
  • Deployment Secrets Management: Environment variables sourced from /Users/cb/Documents/repos/.secrets/repos.env using shell conventions

The deployment pipeline follows this pattern:

cd /Users/cb/Documents/repos/sites/queenofsandiego.com && \
set -a; source /Users/cb/Documents/repos/.secrets/repos.env; set +a && \
aws cloudfront create-invalidation --distribution-id [DISTRIBUTION_ID] \
  --paths "/proposals/jada-charter-proposal-sue.html"

This command:

  • Sources environment variables (containing AWS credentials and CloudFront distribution ID) using set -a/set +a to export all sourced variables into the shell environment
  • Invokes the AWS CLI CloudFront invalidation API for the specific file path
  • Ensures the new HTML file is removed from edge cache within seconds to minutes (typical CloudFront invalidation propagation time)

This approach avoids hardcoding credentials in scripts or version control, using external secret management instead.

Key Architectural Decisions

Why Separate Proposal File vs. Embedded Page

Creating a discrete HTML file in the /proposals/ subdirectory rather than a database-driven proposal system allows:

  • Simplicity: Static files require no backend infrastructure, reducing attack surface and operational overhead
  • Version Control: Every proposal iteration exists as a git commit with audit trail
  • Fast Delivery: Served directly from CloudFront edge locations with minimal latency
  • Naming Flexibility: Proposal-specific URLs (e.g., "sue" variant) can be generated on-the-fly for different sales contexts

Why CloudFront Invalidation Instead of Versioning

The deployment used aws cloudfront create-invalidation rather than S3 versioning or object metadata changes because:

  • Invalidation explicitly purges edge caches, guaranteeing browsers fetch fresh content on next request
  • No need for cache-busting query parameters or filename versioning (e.g., proposal-v2.html)
  • Single source of truth: the HTML file path remains consistent
  • Complies with HTTP cache control headers already set on the distribution

Two Options, Not Four

The pricing presentation deliberately limits choices to two radio button options with one recommended. This follows UX research on decision paralysis: more than three options for similar products increases abandonment rates. The truncated pricing data on the original card ($,050 / $75 / $,575 / $,225) was interpreted as candidate values, but only the clearest, most financially sensible pair was retained for the live proposal.

Verification and Testing

The file discovery process confirmed no existing proposal file at that path:

find /Users/cb/Documents/repos/sites/queenofsandiego.com -name "*proposal*" 2>/dev/null | head -20

This search returned only directory entries, no existing jada-charter-proposal-sue.html file, confirming that the page needed to be created from scratch rather than modified.

Post-deployment, the page is live and accessible at:

https://queenofsandiego.com/proposals/jada-charter-proposal-sue.html

What's Next

  • Price Verification: Confirm that $750 (Option A) and $1,575 (Option B) are accurate against current rate cards
  • Legal Review: Have compliance officer review EPA/MPRSA ash scattering language for jurisdiction-specific accuracy
  • Form Analytics: Track Q&A form submissions to measure proposal-to-lead conversion
  • A/B Testing: Consider deploying variant proposals (different headlines, image treatments, call-to-action text) to separate URLs and measuring engagement differences
  • Mobile Testing: Verify form usability and pricing layout on mobile devices before sharing with prospects

The proposal is now ready to share with stakeholders. The static file approach provides a foundation for rapid iteration: any content changes require only editing the HTML file, re-running the publish script, and invalidating the CloudFront cache—no database migrations or backend redeploy cycles needed.

```