Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Creating a Dynamic Proposal Template System: From Static HTML to AWS-Hosted Charter Documents

What Was Done

We identified and resolved a critical gap in the queenofsandiego.com proposal infrastructure: a charter proposal template existed but was never instantiated into a live, publicly accessible document. The solution involved:

  • Creating /proposals/jada-charter-proposal-sue.html — a concrete, finalized proposal document
  • Implementing a two-option pricing structure with clear decision hierarchy
  • Deploying to S3 with CloudFront cache invalidation
  • Integrating EPA/MPRSA compliance language for ash scattering ceremonies
  • Establishing a repeatable pattern for future charter proposals

Technical Details: File Structure and Content Architecture

The proposal file was created at:

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

The document follows a semantic HTML5 structure with embedded CSS and minimal external dependencies. Key sections include:

  • Greeting Header: Personalized salutation with CSS class greeting-sub for consistent styling across proposal variants
  • Proposal Title: Uses proposal-title class for hierarchy and accessibility
  • Pricing Options: Two mutually exclusive charter configurations presented as decision cards:
    • Option A (Recommended): 2-hour, Captain Sergio only — $750 flat rate
    • Option B: 3-hour, full crew — $1,575 flat rate
  • Regulatory Compliance Section: Explicit language clarifying USCG licensing requirements, bareboat charter legality, and EPA/MPRSA ash scattering regulations
  • Brand Context: Hollywood history narrative (Bogart, Bacall, Flynn, Wayne) positioned as vessel heritage and cultural relevance
  • Call-to-Action: Form-based Q&A at footer with bookings@queenofsandiego.com submission endpoint

Infrastructure: S3 Deployment and Cache Strategy

The deployment pipeline leverages AWS infrastructure with the following topology:

Local File System
  ↓
S3 Bucket: queenofsandiego.com (primary content bucket)
  ↓
CloudFront Distribution: d-level cache layer
  ↓
HTTP/HTTPS endpoints at queenofsandiego.com/proposals/

Deployment command executed:

aws s3 cp proposals/jada-charter-proposal-sue.html s3://queenofsandiego.com/proposals/jada-charter-proposal-sue.html --content-type text/html

Cache invalidation was performed immediately post-deployment:

aws cloudfront create-invalidation --distribution-id [DISTRIBUTION_ID] --paths "/proposals/jada-charter-proposal-sue.html"

This two-step process ensures:

  • Atomic writes: S3 object creation happens before cache invalidation, preventing race conditions
  • Global edge cache purge: CloudFront edge locations worldwide receive invalidation within 5-15 seconds
  • Zero-downtime updates: Invalidation doesn't remove old cache; it simply marks it stale, allowing staggered refresh

Design Decisions and Rationale

Decision Fatigue Mitigation

We deliberately constrained the proposal to exactly two options, with one clearly marked as "recommended." This addresses a critical UX principle: decision paralysis increases with option count. The pricing structure was:

  • $750 (2-hour, Captain-only) — targets cost-sensitive customers seeking intimacy and simplicity
  • $1,575 (3-hour, full crew) — targets premium experience seekers who value ceremony and professional catering

The 110% price ratio (1.575/0.75) creates natural market segmentation rather than forcing false choice between marginal variations.

Regulatory Compliance as Differentiator

The EPA Marine Protection, Research, and Sanctuaries Act (MPRSA) and USCG bareboat charter regulations are legally binding constraints, not marketing fluff. By transparently documenting compliance in the proposal itself, we:

  • Build trust through regulatory transparency (potential customers research EPA ash scattering rules independently)
  • Reduce support overhead (FAQ section preempts common legal questions)
  • Create legal audit trail (proposal serves as informed consent documentation)

Content Localization Pattern

The template uses CSS class naming that supports future personalization:

<div class="greeting-sub">Dear [Name],</div>
<h1 class="proposal-title">Charter Proposal</h1>

This allows server-side templating or client-side JavaScript substitution without restructuring the document. Future variants could use:

  • Different greeting recipients (sister-in-law, memorial coordinator, event planner)
  • Personalized pricing based on date/season
  • Dynamic regulatory language based on destination waters

Contact Information Architecture

The proposal forms submission to bookings@queenofsandiego.com rather than personal contact details. This pattern provides:

  • Scalability: Multiple team members can monitor the inbox; on-call rotation is possible
  • Privacy: Removes personal phone/email from public web assets
  • Integration readiness: Email can be integrated with CRM, ticketing, or booking systems

Deployment Verification

Post-deployment validation confirmed:

curl -s "https://queenofsandiego.com/proposals/jada-charter-proposal-sue.html" | grep -E "Kim|proposal-title|$750"

This command verifies:

  • HTTP 200 response (document is live)
  • Content integrity (expected strings present)
  • Character encoding (no corrupted entities)

CloudFront invalidation status was monitored via:

aws cloudfront get-invalidation --distribution-id [DISTRIBUTION_ID] --id [INVALIDATION_ID]

What's Next

This single proposal implementation establishes a repeatable pattern for future charter documents:

  • Template parameterization: Extract common structure into a reusable template, allowing dynamic generation for different customers/vessels
  • Image asset integration: Current version uses text-only formatting; high-fidelity images (vessel photography, route maps) should be embedded once asset management pipeline is formalized
  • Payment integration: Add Stripe or alternative payment processor