Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building an Ops Dashboard: Consolidating Business Tools into a Single Control Center

Managing a multi-property event booking and charter business requires juggling dozens of tools, spreadsheets, payment systems, and deployment pipelines. Over the past development session, I rebuilt the ops dashboard at https://ops.queenofsandiego.com/ to serve as a centralized command center for all critical business operations. This post walks through the architecture, decisions, and exact implementations that went into this rebuild.

What Was Done

The ops page went from a basic landing page to a comprehensive business operations dashboard featuring:

  • A Payments section with live Stripe deposit links, Zelle routing, and balance tracking
  • A Public Sites section linking to all customer-facing properties
  • Consolidated links to External Platforms (Stripe, AWS, DocuSign, ImprovMX, Instagram)
  • Development tools organized by category (Google Apps Script, DynamoDB, CloudFront)
  • Quick-access buttons for the most frequently used operations (deposit collection, recent payments)

Technical Details

File Structure and Deployment

The ops page lives at:

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

This is deployed to an S3 bucket (ops.queenofsandiego.com) and distributed via CloudFront. The deployment process uses S3 sync with cache invalidation:

aws s3 cp /Users/cb/Documents/repos/sites/ops/index.html s3://ops.queenofsandiego.com/index.html
aws cloudfront create-invalidation --distribution-id [DIST_ID] --paths "/*"

The distribution ID is stored in project handoff documentation to ensure consistent deployments across team members.

Payments Section Architecture

The Payments section is the hub for all transaction workflows. It includes:

  • Stripe Integration: Live payment links created programmatically. The deposit link (https://buy.stripe.com/dRmdR29XnfJlfdC6A2fjG0f) was generated as a Stripe Price object set to $1,560.00 and automatically created as a checkout link. This allows customers to pay deposits without needing custom checkout code.
  • Multiple Payment Methods: Alongside Stripe, Zelle routing information (Sail JADA Charters LLC / 619-986-7344) is displayed as a fallback for customers who prefer ACH transfers.
  • Linked Event Pages: Sub-links to event-specific payment pages (e.g., $125 birthday sail deposit) that share the same Stripe merchant account but use different products.
  • Balance and Payouts: Quick-access links to Stripe Dashboard balance reports and recent transaction history.

The decision to centralize payment links here rather than scatter them across multiple pages reduces the cognitive load for operations staff and creates a single source of truth for payment collection.

Public Sites Section

Customer-facing properties are organized with direct links:

  • sailjada.com — Main charter booking site with sticky modal booking flow
  • queenofsandiego.com — Brand/portfolio site
  • Events Hub — Centralized listing of all bookable events
  • burialsatseasandiego.com — Specialized service microsite

Each property has its own S3 bucket and CloudFront distribution to allow independent scaling and cache management. The ops page serves as the dispatch point to monitor and access these properties.

Infrastructure and Integration Points

AWS Infrastructure

The ops page links to several AWS services:

  • S3 Buckets: Direct links to buckets for ops, jada-images (JADA sailing assets), event properties, and event-specific image storage.
  • CloudFront Distributions: Separate distribution IDs for each public site. When deploying changes to event pages (like the birthday and gipsykings sites), the workflow involves uploading HTML and assets to S3, then invalidating the corresponding CloudFront distribution to purge edge cache.
  • DynamoDB: Link to the jada-crew-dispatch table used for real-time crew assignment and booking state management.

Google Apps Script Integration

Two separate GAS projects are linked from the ops page:

  • Booking Engine GAS: Handles form submissions, email notifications, and calendar syncing for event bookings across all properties.
  • Rady Shell GAS: A separate script project managing the Rady Shell events calendar and specialized booking workflows for that venue.

Separating these projects prevents a single failure from cascading across all properties and allows different release cycles and testing approaches.

External Platforms

The ops page now consolidates login links to:

  • Stripe Dashboard: Payment processing, balance settlement, and payout management.
  • DocuSign: Waiver collection and document signing (critical for charter operations).
  • ImprovMX: Email alias management for bookings@queenofsandiego.com, captains@sailjada.com, etc.
  • AWS Console: Direct access to S3, CloudFront, DynamoDB, and Lambda functions.
  • Instagram @sailjada: Social media management and content scheduling.

Key Decisions and Rationale

Why Centralize Everything in One Page?

Before this rebuild, business operations required opening 15+ tabs across different services. Consolidating these into a single ops page:

  • Reduces context switching: Everything needed for daily operations is accessible from one URL.
  • Enables faster onboarding: New team members get a single reference point instead of digging through documentation.
  • Improves incident response: If a payment or booking fails, the ops person can quickly navigate to the relevant tool without hunting for URLs.
  • Creates audit trails: By routing all critical operations through a known page, we can monitor access patterns and identify bottlenecks.

Payment Link Generation Strategy

Rather than hardcoding payment links, the Stripe payment links are generated programmatically as Stripe Price objects. This allows us to:

  • Track which products and amounts customers are actually being asked to pay.
  • Adjust pricing in Stripe Dashboard without redeploying the ops page.
  • Generate new payment links for ad-hoc amounts (like the $1,560 deposit) without code changes.

Site Organization by Distribution

Each public property (sailjada.com, birthday event site, gipsykings event site) has its own CloudFront distribution and S3 bucket. This separation allows:

  • Independent scaling: A sudden traffic spike to one event site doesn't affect another.
  • Separate invalidation