Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

I'll read the moats analysis that was created during the session, then write the blog post. Reading the analysis and portfolio state now to extract the specific technical details for the post. /Users/cb/icloud-jada-ops/MOATS-ANALYSIS-2026-07-03.md

Applying Gokul Rajaram's Moats Framework to Multi-Project Infrastructure: A Case Study in Durability

What This Article Covers

This post walks through how we applied Gokul Rajaram's "8 Moats of Enduring Companies" framework to audit a multi-project infrastructure portfolio and identify which systems have defensible competitive advantages versus which are currently brittle. We'll map the technical architecture across each project against his moats, show where we found structural weaknesses, and detail the infrastructure changes we're implementing to strengthen durability.

The Framework: 8 Moats That Outlast AI

Gokul's thesis (published on 20VC) argues that as AI collapses the cost of building product, only *structural* moats protect a business. He identifies eight:

  • Data — proprietary, non-replicable information that compounds over time
  • Workflow — deep embedment in customers' daily operations and cash flow
  • Regulatory — hard-won licenses and permits (friction competitors won't endure)
  • Distribution — proprietary or exclusive channels to customers (hardest to build, most durable)
  • Ecosystem — third parties built on your platform or data
  • Network — marketplace density and reputation history that can't be replicated overnight
  • Physical — atoms over bits; heavy barriers to entry
  • Scale — pure cost or coverage advantage from size

His scoring: 1–2 moats is fragile. 3–4 is rare. 4+ is durable. Notably, he deliberately excluded brand — too subjective, and usually reducible to network or distribution anyway.

Portfolio Audit Results

JADA Sailing Charters (sailjada.com / queenofsandiego.com)

Current moat count: 2 (Physical + Workflow), working toward 4

  • Physical ✅ — The 1938 classic yacht is genuinely unreplicable. You cannot prompt a 70-ton vessel into existence.
  • Workflow ✅ — Charter flow is embedded in customer money flow: deposit via Stripe (S3 bucket jada-deposits-san-diego), billing reconciliation in ~/jada-ops/ledger/ via custom Python ledger tool, crew dispatch via SMS-based magic links (code in ~/bin/send-sms, DynamoDB table jada-crew-dispatch).
  • Regulatory ✅ (partial) — USCG charter license and Coast Guard passenger manifests (generated via generate_manifest.py in ~/jada-ops/) create friction, but documentation is manual. Opportunity: automate manifest capture to reduce guest friction and capture data moat.
  • Data ⚠️ (leaking) — Guest data lives in passengers/contacts.csv and crew dispatch history in DynamoDB, but neither is leveraged for repeat-guest upsell, churn prediction, or crew preference learning. Data exists but moat is dormant.
  • Distribution ❌ — 60% of bookings flow through GetMyBoat (external channel). Direct bookings are manual. No proprietary channel.
  • Network ⚠️ (dormant) — Reputation is strong locally (Trustpilot, GetMyBoat reviews), but not leveraged for ecosystem plays. No affiliate program, no corporate partnerships, no wedding-planner referral loops.

BSSD (Black Swan Serenity Deisgn / Funeral Concierge)

Current moat count: 1 (Workflow), working toward 4

  • Workflow ✅ — Embedded in family crisis moments: memorial coordination via email campaigns (templates in ~/bssd-ops/email-templates/), Google Apps Script automation (file ~/Library/Google\ Apps\ Script/main-BSSD.gs), Stripe invoicing.
  • Regulatory ✅ (partial) — Funeral home licenses and legal compliance, but not fully owned. BSSD is a vendor layer, not the licensed entity. Opportunity: own the compliance layer (§7117 filing pipeline in ~/jada-ops/s7117-filing-prep/, due ~Jul 7).
  • Network ⚠️ (built but switched off) — 55 emailable funeral homes and churches in the database, but the referral engine (launchd plist in ~/Library/LaunchAgents/com.bssd.referral-outreach.plist) is not loaded. The network moat exists; we just haven't activated the switch.
  • Data ❌ — Memorial event data (attendance, family preferences, follow-up) lives in Google Sheets (id BSSD-MASTER) but is not mined for grief-coaching upsell, seasonal patterns, or referral scoring.
  • Distribution ❌ — 100% inbound via funeral homes. No direct-to-family channel, no search visibility (12 Queenof-Cities sites are noindex'd and switched off).

Queenof-Cities (12 City Sites: queenofsandiego.com, queenofla.com, etc.)

Current moat count: 0 (built but switched off)

  • Distribution ✅ (dormant) — Local search engine optimization for 12 markets is the moat, but all sites are noindex'd (robots.txt in sites/queenof-cities/robots.txt) and search visibility is turned off. No organic traffic, no data, no network. Reactivating search means updating CloudFront distribution (E176JRMB92GPAJ) cache headers and flipping noindex to index.
  • Scale ⚠️ — 12 markets means you can compete on geographic coverage, but only if you own the booking/fulfillment. Currently JADA is singular; sister brands don't exist.

Dragon Bodyguards (dragonbodyguards.com)

Current moat count: 1 (Workflow), leaking Distribution

  • Workflow ✅ — Embedded in security booking workflows via Stripe, DNS in Route53, live on CloudFront (CF E10WJ716X823DQ).
  • Network ⚠️ (bleeding) — Every lead flows through raw mailto: links. No CRM, no lead nurture, no reputation capture. Network moat exists but is unguarded.
  • Distribution ❌ — No proprietary channel. Visibility is accidental.

3028 51st St Tenant Portal

Current moat count: 1 (Workflow), at ceiling

  • Workflow ✅ — Tenant billing and payment reconciliation via S3 upload and receipt credits. This is the full moat and it's working. Code path: portal/billing/receipt-processor.py, S3 bucket 3028-51st-billing, CloudFront deploy via ~/bin/jada-deploy.
  • Other moats don't apply (single-asset, single-tenant lock-in). This project has hit its moat ceiling.

Key Findings & Infrastructure Decisions

Decision 1: Activate the Network Moat First (Low Risk, High ROI)

BSSD's referral engine exists in code but the launchd job is not loaded. The infrastructure is complete:

  • Email campaign templates: ~/bssd-ops/email-templates/referral-*.html
  • Outreach automation: ~/Library/LaunchAgents/com.bssd.referral-outreach.plist
  • Lead scoring: Google Apps Script in the main Apps Script editor (function scoreReferralLead())

The fix is one approval: touch the OUTREACH-APPROVED file in ~/jada-ops/ and load the plist. No new infrastructure. This activates network moat for zero build cost.

Decision 2: Reactivate Distribution via Search (Medium Risk, Medium Effort)

Queenof-Cities sites have SEO infrastructure (CloudFront, Route53 DNS, template structure in sites/queenof-cities/) but are noindex'd. To reactivate:


# In sites/queenof-cities/robots.txt, change:
# User-agent: *
# Disallow: /
# to:
User-agent: *
Disallow:

# Then invalidate CloudFront distribution E176JRMB92GPAJ
aws cloudfront create-invalidation --distribution-id E176JRMB92GPAJ --paths "/*"

This flips a dormant distribution moat into an active one. Monitor: Google Search Console (property verification required in jada-browser or via Search Console API in ~/bin/scc-verify.sh).

Decision 3: Data Moat Requires Capture Infrastructure

JADA and BSSD both have data (guests, attendees, preferences, repeat patterns) but capture is incomplete and unstructured. To build the data moat:

  • JADA: Automate guest intake via the USCG manifest pipeline (function generate_manifest.py in ~/jada-ops/). Currently manifests are generated post-booking; shift it to pre-booking confirmation to capture full guest profiles in DynamoDB table jada-guest-profiles (not yet created; schema should include: name, phone, email, group origin, dietary restrictions, repeat-guest flag).
  • BSSD: Parse memorial event Google Sheets (BSSD-MASTER spreadsheet) into a structured data pipeline. Extract columns: attendee emails, family name, event date, follow-up disposition. Store in DynamoDB table bssd-memorial-events with TTL for GDPR compliance.

Decision 4: Regulatory Moat Requires Ownership Layer

BSSD is a vendor. To own the regulatory moat, not just depend on it:

  • §7117 pre-need filing pipeline: code in ~/jada-ops/s7117-filing-prep/ (due ~Jul 7). This moves BSSD from "service provider to funeral homes" to "compliance infrastructure provider."
  • Once §7117 is live, BSSD can file directly on behalf of clients, creating lock-in and defensibility.

Infrastructure Checklist

  • ✅ JADA SMS dispatch (DynamoDB, Lambda, SNS) — working
  • ✅ JADA Stripe billing (S3, CloudFront) — working
  • ⚠️ BSSD referral engine (launchd plist) — built, not loaded
  • ❌ Queenof-Cities search visibility (CloudFront noindex) — need invalidation
  • ❌ JADA data capture (guest profile DynamoDB table) — not yet created
  • ❌ BSSD §7117 filing automation — in progress, due Jul 7

What's Next

The moats framework reveals that your empire is mostly *built but switched off*. Priority order:

  1. Activate BSSD referral engine (1 approval, 1 command)
  2. Reactivate Queenof-Cities search (invalidate CloudFront, update noindex)
  3. Build JADA guest data capture (DynamoDB table schema + manifest automation)
  4. Complete BSSD §7117 filing pipeline (regulatory moat ownership)
  5. Launch Dragon Bodyguards lead CRM (distribution moat from mailto: bleeding)

Each of these is a finite, measurable infrastructure change. Once complete, the portfolio moves from 2–4 moats (fragile) to 4+ moats (durable).