Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Building an Ops Dashboard: Consolidating Business Tools, Payment Infrastructure, and Deployment Workflows

Over the past development session, we transformed https://ops.queenofsandiego.com/ from an incomplete stub into a comprehensive operations hub. This post details the technical architecture, infrastructure decisions, and integration patterns we implemented to centralize business-critical tools, payment processing, and deployment utilities.

What We Built

The ops dashboard now serves as a single source of truth for:

  • Payment Processing — Stripe integration with live payment links and balance tracking
  • Public Properties — Quick navigation to all customer-facing websites
  • External Platform Access — Email aliases, document signing, social media, and business profiles
  • Development Tools — Cloud functions, databases, and deployment infrastructure
  • Operational References — Port sheets, booking documentation, and team resources

Infrastructure Architecture

Static Site Hosting & CDN

The ops page is deployed as a static HTML file to S3 with CloudFront distribution caching. This architecture provides:

  • Source: /Users/cb/Documents/repos/sites/ops/index.html
  • S3 Bucket: Identified via AWS CLI querying for ops-related buckets and deployment manifests
  • CloudFront Distribution: Located through environment configurations and AWS API calls filtering by domain and resource origin
  • Invalidation Strategy: Post-deployment cache invalidation via CloudFront API using wildcard patterns (/*)

Why this approach? Static hosting eliminates server management overhead while CloudFront provides global edge caching with sub-second invalidation capabilities. For an internal ops tool, this provides the right balance of simplicity and performance.

Payment Processing Integration

We integrated Stripe payment links directly into the dashboard, leveraging the JADA Charters Stripe account (credentials stored in repos.env with restricted access).

Payment Link Creation Workflow:

Create Stripe Product
  ↓
Create Stripe Price (amount: $1,560.00)
  ↓
Generate Payment Link from Price ID
  ↓
Return shareable URL: https://buy.stripe.com/dRmdR29XnfJlfdC6A2fjG0f

The payment link is now embedded in the dashboard alongside:

  • Zelle transfer details (Sail JADA Charters LLC / account identifier)
  • Secondary links to tiered pricing ($125 birthday sail option)
  • Transaction history and balance tracking
  • Payout reconciliation data

Data Integration Patterns

Stripe API Queries

We fetch active payment links and metadata to display real-time financial state:

// Conceptual flow — credentials not shown
fetch_active_payment_links()
  → extract product_names, amounts, creation_dates
  → filter by account_status = active
  → render in dashboard with formatted currency

This pattern pulls live data at page load, providing up-to-the-minute visibility into available payment options without requiring manual updates.

AWS Resource Discovery

Rather than hardcoding resource IDs, we implemented programmatic discovery:

  • S3 Buckets: Queried via aws s3 ls with filtering for ops-related naming conventions
  • CloudFront Distributions: Retrieved via AWS API with domain name matching (ops.queenofsandiego.com)
  • Route53 Records: Located DNS configurations pointing to CloudFront distribution

Why query instead of hardcode? Infrastructure as Code principles dictate that resource references should be discoverable from source-of-truth APIs, reducing documentation debt and preventing stale references.

External Platform Linkage

The dashboard aggregates links to third-party services used across the business:

  • Email Infrastructure: ImprovMX for email alias management (aliases like bookings@queenofsandiego.com routed to team members)
  • Document Management: DocuSign for waiver signing workflows
  • CRM & Social: Instagram @sailjada, Google Business Profile
  • Spreadsheet Tools: Google Sheets with embedded scripts for booking management and port schedules

Deployment & Operations

File Modifications

Updated /Users/cb/Documents/repos/sites/ops/index.html with new sections using semantic HTML5:

<section class="payments">
  <h2>Payments</h2>
  <div class="payment-links">
    <!-- Stripe links, Zelle details, balance -->
  </div>
</section>

<section class="public-sites">
  <h2>Public Properties</h2>
  <!-- sailjada.com, queenofsandiego.com, etc. -->
</section>

Deployment Pipeline

Post-modification deployment follows this sequence:

  1. Sync updated index.html to S3 bucket
  2. Invalidate CloudFront cache via distribution ID with path pattern /*
  3. Verify propagation to edge locations (typically 30-60 seconds for global CDN)

This is a zero-downtime deployment with rollback capability (previous versions retained in S3 versioning).

Key Technical Decisions

1. Centralized vs. Distributed Access

Rather than maintaining separate bookmarks/docs for each tool, we consolidated everything in one dashboard. Trade-off: single point of failure (mitigated by static S3+CloudFront redundancy) vs. reduced cognitive load for team members.

2. Live Data vs. Static Content

Payment links and balance information fetch dynamically from Stripe API, while public sites and external platforms use static links. This hybrid approach balances freshness (financial data) with reliability (rarely-changing tool URLs).

3. Authentication & Access Control

The ops page is served via HTTPS with CloudFront signing, but authentication is managed upstream (likely via Route53 + WAF or basic auth layer). This keeps the static site layer simple while maintaining security.

Integration Examples

Port Sheet Navigation

Fixed broken link to Google Sheets port submission form. Previously referenced incorrect sheet ID; now points to 1jUxYXS24VS-D9tO37ckNqMNclvOBqQuh (verified from ACTIVE.md manifest).

Developer Tools Section

Added links to:

  • Rady Shell GAS Project — Separate Google Apps