Consolidating Operational Infrastructure: Building a Unified Control Panel for Multi-Domain Event Booking

```html

What Was Done

Over the course of this session, we consolidated fragmented operational tooling across multiple domains (sailjada.com, queenofsandiego.com, and associated event booking sites) into a single, unified control panel accessible at https://ops.queenofsandiego.com/. This involved:

Creating a comprehensive ops dashboard with navigation to all critical business systems
Integrating payment processing (Stripe) with a public-facing deposit link
Centralizing access to event-specific deployment infrastructure (S3 buckets, CloudFront distributions)
Documenting all external platform integrations (email aliases, digital signatures, CMS tools)
Establishing a single source of truth for deployment workflows and payment reconciliation

Technical Architecture & Infrastructure

The ops page serves as an aggregation layer—a centralized entry point to distributed infrastructure components. The architecture is intentionally flat to minimize cognitive overhead during time-sensitive operations (e.g., event deployments, payment collection).

Static Site Hosting

The ops page is hosted on S3 with CloudFront distribution for global edge caching and SSL termination. The file structure is:

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

This single HTML file contains all navigation, documentation, and quick-access links. The design prioritizes readability and scanability—color-coded sections (green for payments, blue for platforms, etc.) allow operators to find resources in seconds rather than minutes.

Domain Routing

DNS routing via Route53 directs ops.queenofsandiego.com to the CloudFront distribution. This keeps ops infrastructure under the primary domain while remaining logically separate from customer-facing sites.

Event-Specific Infrastructure

The ops page catalogs deployment endpoints for multiple event sites, each with its own S3 bucket and CloudFront distribution:

Birthday Event Site: S3 bucket for /rady-shell-events/sites/birthday/, CloudFront distribution for invalidation and cache control
Birthday Afternoon Event Site: Separate S3 bucket for /rady-shell-events/sites/birthday-afternoon/, independent CloudFront distribution
Public Booking Sites: sailjada.com, queenofsandiego.com, and burialsatseasandiego.com with their respective distribution chains

Each event site uses the same deployment pattern: Git-based source control → local file edits → S3 push → CloudFront invalidation. The ops page documents this workflow and provides direct links to CloudFront distribution IDs for invalidation.

Payment Processing Integration

The single biggest operational gap was the absence of a centralized payment link. We created a Stripe payment link for a $1,560.00 deposit charge:

https://buy.stripe.com/dRmdR29XnfJlfdC6A2fjG0f

The process:

Accessed Stripe API using credentials stored in repos.env
Created a product: "JADA Charter — $1,560.00"
Created a price object with USD currency and fixed amount
Generated a payment link with success/cancel redirect URLs
Embedded the link in the ops dashboard under a "Payments" section

The payment link is public and can be shared with customers without exposing internal infrastructure. Stripe handles PCI compliance, tokenization, and webhook events for reconciliation.

Operational Tooling Aggregation

The ops page now provides single-click access to:

Payment & Accounting

Stripe deposit link ($1,560)
Stripe balance and payout history
Zelle payment details for non-card payments
Secondary payment links ($125 birthday sail deposits)

Email & Communications

ImprovMX email alias forwarding configuration
SES (Simple Email Service) for transactional email
Sendgrid integration points (if applicable)
Email template repository

Customer & Document Management

DocuSign integration for waivers and contracts
Proposals and quote generation system (replacing ad-hoc Word docs)
Customer database (DynamoDB jada-crew-dispatch table)

Site Management & Deployment

Direct links to each public site (sailjada.com, queenofsandiego.com, burialsatseasandiego.com)
Event booking sites (Birthday, Birthday Afternoon, others)
CloudFront distribution IDs for cache invalidation
S3 bucket access for asset uploads and deployments

Backend & Database Tools

AWS DynamoDB (jada-crew-dispatch table for crew scheduling)
Google Apps Script projects (event booking engine, Rady Shell integration)
Port submission spreadsheet (Sheraton Port Service data)

Key Architectural Decisions

Why Centralize Everything in One Page?

Under time pressure (event bookings, payment collection, deployment emergencies), operators need to find tools in seconds. A flat page with color-coded sections minimizes context-switching and reduces the likelihood of using outdated links or forgotten credentials.

Why Keep Deployments in the Same Workflow?

Birthday and Birthday Afternoon event sites went through simultaneous updates (e.g., modal form logic, booking flow refactoring). By keeping their deployment infrastructure documented together on the ops page, we reduce the risk of deploying to one site and forgetting the other.

Both sites follow the same deployment pattern:

# Edit local HTML
vim /Users/cb/Documents/repos/sites/queenofsandiego.com/rady-shell-events/sites/birthday/index.html

# Deploy to S3
aws s3 cp index.html s3://[BUCKET]/index.html

# Invalidate CloudFront cache
aws cloudfront create-invalidation --distribution-id [DIST_ID] --paths "/*"

Why Stripe for Deposits?

Stripe provides:

Public-safe links: Payment links don't expose infrastructure or business logic
Compliance: PCI-DSS handled entirely by Stripe
Webhooks: Automated reconciliation with accounting systems
Flexibility: Easy to create additional links for different charge amounts (e.g., $125 birthday event, $500 standard deposit)

What's Next

Proposal Automation: Replace manual Word doc generation with a system that builds polished proposals from customer data, feeding directly into the booking workflow
Payment Reconciliation: Implement webhook handlers to auto-reconcile Stripe