Building JADA's Proposal Designer: From Static Templates to Dynamic Charter Documents

```html

What Was Done

We implemented a lightweight proposal document generator for JADA's charter booking workflow. The system takes user context (guest name, event date, party size) and renders a self-contained HTML document that serves as both a web preview and a print-ready PDF artifact. This replaced a manual email-based proposal process that required design handoff and version control overhead.

Technical Architecture

The proposal designer operates as a thin template layer without backend rendering complexity:

Frontend rendering: Single-pass HTML generation with inline CSS (no external asset dependencies)
No JavaScript required: CSS Grid and Flexbox handle all layout and responsiveness
Print-native: Media queries optimize for both screen and paper output
Self-contained: Eliminates CDN/asset delivery layer for proposal artifacts

The document structure follows a predictable DOM hierarchy that allows CSS-only styling variations without DOM manipulation or script dependencies. This was a deliberate choice to maximize portability—proposals can be shared as plain HTML files, dropped into email, or served directly from S3 without rendering infrastructure.

Design System Integration

The proposal inherits JADA's house style through CSS custom properties and a rigid color palette:

Hero section: Deep navy gradient (#0a1f3a to #0d2747) with 160deg linear gradient for visual depth
Accent gold: #c9a24b (labels) and #e3c478 (highlights) for warm sophistication
Body background: #f7f4ec (warm off-white) with #1c2733 slate text for contrast
Serif headings: Georgia for nautical elegance; sans-serif body copy uses system-ui stack for rendering consistency across OS platforms

The color palette was selected to evoke San Diego's maritime heritage while maintaining WCAG AA contrast ratios for accessibility. The warm gold against navy creates visual hierarchy without relying on brightness shifts alone.

Responsive Layout Strategy

The mobile-first approach sets constraints at the root level:

Page container: max-width: 720px centered with margin: 0 auto
Generous padding: 32px horizontal, 44px vertical sections (increases on larger screens)
Flexbox fact cards: Wrap naturally at smaller viewports, grid-aligned at desktop
Hero typography scales from 38px h1 on mobile to larger on desktop (handled via media queries)
Print media: Removes page shadows, adjusts margins, and ensures color preservation in PDF export

The 720px max-width constraint ensures single-column readability on mobile while remaining elegant on desktop. This was benchmarked against common email client widths and PDF readers.

CSS Architecture Decisions

Why inline CSS: Proposal documents are distributed as standalone artifacts. External stylesheets introduce dependency management and cold-start delays. Inline CSS trades file size (negligible for documents under 50KB) for guaranteed rendering fidelity across email clients, S3 direct serve, and print contexts.

Box-sizing border-box reset: Applied globally to prevent padding collapse in card components. This ensures .fact cards maintain consistent width calculations when padding is applied.

Font stack ordering: system-ui, -apple-system, "Segoe UI", Roboto, sans-serif ensures native system fonts render first, reducing FOUT (flash of unstyled text) and eliminating web font delivery latency.

Component Patterns

Hero section: Layered background gradient with semantic spacing hierarchy:

.hero .kicker        /* Uppercase accent label */
.hero h1              /* Primary title with .gold italic span */
.hero .subtitle       /* Supporting narrative copy */
.quickfacts           /* Flex row of stat cards */.fact .label + .fact .value /* Two-level typography per card */

The kicker-title-subtitle-facts pattern establishes visual rhythm and guides the eye through key information. The gold emphasis on specific words (e.g., "the Bay") connects to brand identity without oversaturating the palette.

Section cards: Reusable .section class with consistent padding (44px 32px) and optional .card wrapper for shadowed panels. This allows flexible composition—some sections are full-width, others are nested card components.

Print Optimization

The design includes a @media print block that:

Removes page container shadow (eliminates gray borders in PDF)
Preserves background colors explicitly with background: #f7f4ec !important
Adjusts margins to 0.5 inch for standard letter-size paper (8.5" x 11")
Forces page breaks before major sections to prevent content orphaning
Sets font-size: 11px for body text (standard for printed documents)

These rules were tested with Chrome DevTools print preview and exported through Adobe InDesign to verify PDF output matches the web preview.

Data Injection Points

The template defines specific text nodes for dynamic population:

Mollie — Guest name inserted by backend or query param
Saturday, June 14 — Formatted date from booking system
12 Guests — Party size from form
3 Hours — Charter duration from product config

These span wrappers allow server-side templating (via Jinja, Handlebars, or EJS) to inject values without parsing HTML. The wrapper divs maintain styling context even if content is empty (fallback text remains visible).

Infrastructure & Delivery

S3 storage: Final HTML documents are stored in s3://jada-proposals/charter/ with a standard key format: proposal-{booking-id}-{timestamp}.html. Objects are set to private by default with pre-signed URLs issued for client access.

CloudFront distribution: Proposal assets (if any external images are added later) route through CloudFront distribution ID E2JADA3XYZ... with 24-hour cache TTL and gzip compression enabled.

Route53 DNS: Proposal preview URLs resolve via proposals.sailjada.com, routed through an S3 alias record pointing to the bucket's regional endpoint.

Key Design Decisions

No JavaScript: Reduces complexity, improves loading speed, and eliminates client-side rendering failures in email and PDF contexts.
Mobile-first CSS: Base styles assume 375px viewport; media queries enhance for larger screens. This ensures proposals are readable on any device