Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Consolidating Operational Tools: Building a Unified Command Center at ops.queenofsandiego.com

Operations dashboards are only useful if operators can actually find what they need. After reviewing scattered tools, spreadsheets, and payment systems across multiple platforms, we consolidated everything into a single, organized hub. This post details how we restructured the ops page to serve as the single source of truth for payments, public properties, external integrations, and development resources.

What Was Done

The ops page at https://ops.queenofsandiego.com/ serves as the operational nerve center for Sail JADA operations. We restructured it from a basic index to include:

  • Payments section — Direct Stripe deposit link, Zelle transfer details, birthday sail pricing, and financial tracking
  • Public Sites section — Quick links to all customer-facing domains
  • External Platforms section — Email aliases, document management, social media, and business profile tools
  • Development section — Google Apps Scripts, DynamoDB tables, and infrastructure references
  • Link corrections — Fixed hardcoded Google Drive IDs to point to actual operational sheets

Technical Details

File Structure and Updates

All changes were made to a single file:

/Users/cb/Documents/repos/sites/ops/index.html

This is a static HTML file served directly from S3, meaning no backend processing or templating. This keeps the ops page blazingly fast and eliminates any single point of failure in a database or API layer.

Payments Section Architecture

The Payments section now includes:

  • Primary CTA — A prominently styled $500 Deposit button linking directly to the Stripe checkout page for deposit payments
  • Stripe integration — Live payment link (not a test link) for processing immediate deposits
  • Zelle fallback — Bank transfer details (Sail JADA Charters LLC / 619-986-7344) for clients who prefer ACH transfers
  • Sub-links — Links to the $125 birthday sail pricing tier and recent payment records
  • Balance tracking — Reference to payouts and account balance documentation

Why we did this: Operators previously had to navigate between Stripe, Zelle, and separate Google Sheets to handle deposits. Centralizing payment entry points reduces friction and ensures nothing slips through cracks during peak booking periods.

Public Sites Aggregation

Rather than maintaining separate navigation for each property, we created a dedicated section linking to:

  • sailjada.com — Main booking and brand site
  • queenofsandiego.com — Corporate/organizational site
  • events.queenofsandiego.com — Event booking hub
  • burialsatseasandiego.com — Specialized service site
  • tipsbox.com — Third-party tips/gratuity platform

This serves two purposes: (1) operators can quickly verify all properties are live and accessible, and (2) provides a checkpoint to ensure DNS/CloudFront is functioning across the entire domain portfolio.

External Platforms Integration

We catalogued critical third-party integrations under a dedicated section:

  • ImprovMX — Email alias forwarding for ops@queenofsandiego.com and other branded addresses
  • DocuSign — Digital waivers and contract management (critical for liability)
  • Instagram @sailjada — Social media presence and marketing
  • Google Business Profile — Local SEO and customer-facing business information

Why consolidate here: Operators need to know which platforms are active and where to escalate issues. A missing email alias or unavailable DocuSign account directly impacts customer onboarding.

Infrastructure and Deployment

S3 and CloudFront Setup

The ops page is served via:

  • S3 bucket — Static hosting for the ops domain
  • CloudFront distribution — CDN caching and HTTPS termination
  • Route53 DNS — DNS routing for ops.queenofsandiego.com

Deployment command:

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

The invalidation clears CloudFront's edge cache, ensuring the updated page is live globally within seconds rather than waiting for the default TTL.

Link Corrections: Drive ID Fixes

One critical fix involved correcting hardcoded Google Drive IDs. Previously, the Port Sheet link pointed to an incorrect or outdated sheet. We updated it to:

https://docs.google.com/spreadsheets/d/1jUxYXS24VS-D9tO37ckNqMNclvOBqQuh/edit

This is the authoritative Sheraton submission sheet maintained in ACTIVE.md, the internal reference document. Hard-coding IDs is not ideal (we should consider a config management layer), but for a low-traffic operational tool, the trade-off between simplicity and dynamism is reasonable.

Development Resources Section

Google Apps Scripts

We added references to two separate GAS projects:

  • Booking engine — Handles customer-facing reservations and payment triggers
  • Rady Shell GAS project — A separate script for venue-specific operations (kept in a distinct project for isolation and scalability)

Why separate scripts: This allows independent scaling, testing, and deployment. The booking engine can be updated without risking the Rady Shell automation, and vice versa.

AWS DynamoDB Reference

We added a direct link to the jada-crew-dispatch DynamoDB table. This table is critical for:

  • Real-time crew scheduling
  • Dispatch coordination
  • Historical dispatch records

Why expose this in ops: DynamoDB tables can be queried directly from the AWS console without CLI tools. Including the table name allows operations staff to quickly verify data integrity or investigate dispatch delays without needing engineering support.

Key Decisions

  • Static HTML over dynamic pages — No templating layer means no build process, no cache invalidation issues beyond CloudFront, and near-zero latency
  • Centralized payment links — Rather than scattered Stripe, Zelle, and accounting documents, all payment methods are now on the first screen
  • Public sites as a verification checklist — Including links to all customer-facing properties allows operators to spot DNS or deployment issues immediately
  • Development tools exposed to operations