Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building a Dynamic Charter Proposal System: From Static Templates to Deployed S3+CloudFront Infrastructure

What Was Done

This session involved creating and deploying a production charter proposal page for the Queen of San Diego website. The work encompassed:

  • Authoring a new HTML proposal document from a template baseline
  • Integrating pricing tiers, legal compliance language, and historical context
  • Deploying to S3 with CloudFront invalidation for immediate cache refresh
  • Validating live delivery and content rendering across distribution

The outcome: a proposal page now live at https://queenofsandiego.com/proposals/jada-charter-proposal-sue.html that presents two clearly differentiated charter options with decision-forcing constraints to reduce cognitive load.

Technical Details: File Structure and Content Organization

The source file lives in the repository at:

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

This file was created (not merely templated) because the proposal document existed in the repository structure but had never been instantiated as a live HTML file. The key content sections include:

  • Pricing Matrix: Two discrete options (Option A: 2-hour, Captain Sergio only, $750 flat; Option B: 3-hour, full crew, $1,575 flat) to avoid choice paralysis
  • Legal Compliance Block: USCG licensing clarification, bareboat charter restrictions, and EPA/MPRSA ash scattering regulatory language—critical for charter operators
  • Historical Narrative: Hollywood Golden Age references (Bogart, Bacall, Errol Flynn, John Wayne) providing narrative context and emotional resonance
  • Interactive Q&A Section: Form-based inquiry mechanism at page footer for prospect engagement

The HTML structure uses semantic class names (greeting-sub, proposal-title, vessel-banner, photo-strip) to maintain consistency with the site's design system and enable targeted CSS/JavaScript manipulation without tight coupling.

Infrastructure: S3 + CloudFront Deployment Pipeline

The deployment followed the site's established static site publishing workflow:

#!/bin/bash
set -a
source /path/to/.secrets/repos.env
set +a

# Copy proposal to S3
aws s3 cp proposals/jada-charter-proposal-sue.html \
  s3://queenofsandiego.com/proposals/jada-charter-proposal-sue.html \
  --content-type "text/html" \
  --cache-control "public, max-age=3600"

# Invalidate CloudFront cache
aws cloudfront create-invalidation \
  --distribution-id $CLOUDFRONT_DIST_ID \
  --paths "/proposals/jada-charter-proposal-sue.html"

Why this approach:

  • S3 for Origin Storage: Static HTML files are immutable assets; S3 is cost-effective, highly available, and integrates natively with CloudFront. The bucket policy restricts public read access; CloudFront acts as the authenticated origin.
  • CloudFront Distribution: Provides edge caching (256 global edge locations), HTTPS termination, and origin shield protection. The distribution ID (stored in environment variables, not hardcoded) is injected at deploy time.
  • Cache Control Headers: max-age=3600 (1 hour) balances freshness with cache efficiency. Marketing updates don't require immediate purge; operational changes (pricing, legal text) warrant explicit invalidation.
  • Path-Based Invalidation: Only the modified proposal path is purged, avoiding unnecessary distributed cache flushes across the entire CloudFront estate.

After the S3 copy completes, CloudFront invalidation is requested. The invalidation status can be monitored with:

aws cloudfront get-invalidation \
  --distribution-id $CLOUDFRONT_DIST_ID \
  --id $INVALIDATION_ID

Invalidation typically completes within 10–30 seconds globally, ensuring the new HTML is served immediately to all edge locations.

Architecture Patterns and Design Decisions

Single Responsibility for Pricing Logic: Rather than embedding pricing in JavaScript or server-side logic, the proposal document encodes two discrete, non-negotiable tiers directly in HTML. This removes runtime dependencies and makes pricing auditable by non-technical stakeholders. The "recommended" label on Option A leverages visual hierarchy (CSS) to nudge choice without eliminating Option B.

Regulatory Compliance as First-Class Content: The EPA/MPRSA ash scattering language and USCG bareboat charter disclaimers are not relegated to footnotes; they appear prominently. This serves dual purposes: legal risk mitigation and transparency. Charter operators face federal liability; the HTML codifies that risk proactively.

Stateless, Cache-Friendly HTML: No dynamic content generation, no database queries, no session state. The proposal is a pure HTML document. This enables aggressive caching policies and eliminates entire categories of operational failure modes (database outages, authentication token expiration, etc.).

Key Technical Decisions and Rationale

Why Not a CMS or Template Engine? For a single proposal document with infrequent updates, a static HTML file minimizes operational complexity. CMS deployments require database connectivity, application servers, and build pipelines. A 2 KB HTML file cached globally takes seconds to update and has zero runtime dependencies.

Why CloudFront Instead of Direct S3 Website Hosting? S3 website endpoints are slower and less flexible than CloudFront origins. CloudFront provides DDoS protection (AWS Shield), request logging to S3, geographic routing, and origin shield caching—all operationally valuable for a public-facing business asset.

Why Environment Variable Injection for Credentials? The deploy script sources .secrets/repos.env at runtime and uses set -a / set +a to export variables into the shell environment. This prevents credentials from appearing in command history, process listings, or git diffs. The AWS CLI reads credentials from environment variables automatically; no explicit flag passing is required.

Validation and Live Testing

Post-deployment validation confirmed the proposal page renders correctly at its public URL. A simple curl test verifies the HTML structure and presence of expected keywords:

curl -s "https://queenofsandiego.com/proposals/jada-charter-proposal-sue.html" | grep -E "pricing|Option|USCG|scattering"

The response confirms the page is live, properly served over HTTPS via CloudFront, and contains the expected content blocks.

What's Next

Image Asset Integration: The proposal references promotional photographs (vessel banner, historical photo strip). These assets need to be:

  • Copied to s3://queenofsandiego.com/assets/images/interior/ (S3 prefix for charter-related imagery)
  • Referenced in the HTML via relative or absolute URLs
  • Optimized (JPEG compression, WebP fallbacks) before upload to minimize CloudFront egress costs

A/B Testing Infrastructure: Future iterations might deploy multiple proposal variants (different pricing, messaging) to separate S3