Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building an Operational Dashboard: Consolidating Tools, Payments, and Infrastructure Management

Over the past development session, we significantly expanded the operational capabilities at Queen of San Diego by consolidating scattered tools, payment infrastructure, and deployment utilities into a single ops dashboard. This post covers the technical architecture decisions, infrastructure changes, and the systems integration that enables rapid access to critical business operations.

The Problem: Tool Fragmentation

Before this work, operational tools were scattered across multiple locations—Stripe dashboards, Google Sheets, AWS consoles, deployment scripts, and various documentation files. When time-sensitive tasks came up (like generating a payment link or deploying an updated booking page), there was unnecessary friction in locating the right resource or remembering the correct S3 bucket name or CloudFront distribution ID.

The solution: centralize everything into a single ops dashboard at https://ops.queenofsandiego.com/.

Architecture: File Structure and Deployment

The ops page is deployed using a simple but effective pattern:

  • Source: /Users/cb/Documents/repos/sites/ops/index.html
  • S3 Bucket: Dedicated ops bucket (configured via handoff metadata)
  • CDN: CloudFront distribution with automatic cache invalidation on deploy
  • Deployment: Custom deploy script that syncs HTML to S3 and invalidates CloudFront paths

The deployment command pattern:

aws s3 cp index.html s3://[ops-bucket]/index.html --content-type text/html
aws cloudfront create-invalidation --distribution-id [OPS_DIST_ID] --paths "/*"

This ensures the dashboard is always fresh and globally available within seconds of updates.

Integration Point 1: Payment Processing with Stripe

The primary new section added to ops is the Payments module, which provides immediate access to:

  • Live Stripe deposit link ($1,560.00 JADA charter deposit) — product created programmatically with price and payment link generation
  • Quick-access $500 deposit button for common booking amounts
  • Zelle details for offline payment routing (Sail JADA Charters LLC / 619-986-7344)
  • Recent payment links fetched dynamically from Stripe's API
  • Balance and payout tracking tied to account reconciliation workflows

Instead of navigating to the Stripe dashboard every time, operators can:

  1. Visit ops.queenofsandiego.com
  2. Click the payment link or generate a new one on-demand
  3. Copy/paste the link to clients immediately

The payment link was created using the Stripe API with a specific product ID and price tied to the JADA business entity, ensuring all transactions flow to the correct account.

Integration Point 2: Public-Facing Sites Navigation

The ops dashboard now includes a Public Sites section with quick links to all active web properties:

  • sailjada.com — Main JADA charter website
  • queenofsandiego.com — Brand hub and event portal
  • Events Hub — Central booking and event management
  • burialsatseasandiego.com — Separate service offering
  • Tips Box — Internal guidance for common operations

Each site maintains separate S3 buckets and CloudFront distributions. By centralizing the links, operations staff can quickly navigate between properties without hunting through bookmarks or documentation.

Integration Point 3: Event Deployment Infrastructure

During the same session, we updated two custom event pages with new booking flow logic:

  • /Users/cb/Documents/repos/sites/queenofsandiego.com/rady-shell-events/sites/birthday/index.html
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/rady-shell-events/sites/birthday-afternoon/index.html

Each event site follows this deployment pattern:

1. Update HTML source file locally
2. Deploy to event-specific S3 bucket
3. Invalidate event-specific CloudFront distribution
4. Verify new modal/form elements are present
5. Verify old flow elements are removed

This two-tier modal form approach provides better UX by splitting the booking flow into distinct steps, reducing cognitive load on users during the booking process.

Infrastructure: External Services Connected to Ops

The ops dashboard now surfaces connections to critical external platforms:

  • ImprovMX — Email alias management (routes like bookings@queenofsandiego.com to the correct inbox)
  • DocuSign — Digital waiver and contract signing
  • Instagram @sailjada — Social media account management
  • Google Business Profile — Local business listings and reviews
  • Rady Shell Google Apps Script project — Separate GAS project for Rady Shell event automation (not the main booking engine)
  • AWS DynamoDB — jada-crew-dispatch table for real-time crew scheduling

These connections are curated based on operational frequency—only the tools used regularly appear on the main dashboard, reducing cognitive overhead.

Key Technical Decision: Handoff-Driven Configuration

Rather than hardcoding S3 bucket names and CloudFront distribution IDs, we use a handoff metadata pattern stored in the repos:

File: /Users/cb/Documents/repos/sites/ACTIVE.md (or equivalent handoff docs)
Contains:
- S3 bucket names for each site/event
- CloudFront distribution IDs
- Route53 DNS records
- Deployment credentials and scopes
- Environment variables per site

This approach allows:

  • Single source of truth for infrastructure metadata
  • Easy site/event replication (copy the handoff entry, new site is deployable)
  • Clear audit trail (every infrastructure change is documented)
  • No secrets in code (credentials stored separately in repos.env)

Deployment Verification: What We Check

After deploying birthday and birthday-afternoon pages, we ran specific verification checks:

  • Confirm new two-step modal form elements are present in HTML
  • Confirm old booking flow selectors/classes have been removed
  • Verify S3 object was uploaded with correct content-type (text/html)
  • Verify CloudFront invalidation completed before declaring success

This prevents the common gotcha of deploying code that breaks the site because the old flow logic is still present and conflicting with new elements.

What's Next

Future iterations for the ops dashboard:

  • Automated payment reconciliation — Pull Stripe balance and recent transactions into a weekly summary
  • Deployment quick-links