Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

I'll read the moats analysis file and then write the technical blog post. /Users/cb/icloud-jada-ops/MOATS-ANALYSIS-2026-07-03.md

Applying Gokul Rajaram's Moats Framework to a Multi-Project Portfolio: Physical Assets Meet Distribution and Workflow

What We Did

We audited our entire project portfolio—JADA Sailing, BSSD (a referral engine), Dragon Bodyguards, and a rental property management platform—against Gokul Rajaram's "8 Moats of Enduring Companies" framework. The goal was to identify structural advantages that survive commoditized tooling and AI-driven competition, then map the infrastructure and architectural decisions needed to build from current state (~2 moats) toward durability (4+ moats). Unlike brand or first-mover advantage, Rajaram's framework focuses on defensible structures: data, workflow embedment, regulatory friction, distribution channels, ecosystem effects, network density, physical assets, and scale.

Portfolio Assessment: Where the Moats Actually Are

JADA Sailing + BSSD emerged as the only entity with a realistic path to 4+ moats. JADA owns two irreplaceable moats by default:

  • Physical moat (✅ active): A 1938 classic yacht built and maintained for San Diego Bay operations. Zero replication cost for competitors—you can't prompt a vessel into existence. This moat compounds: the older and more storied the boat, the stronger the pricing power and customer willingness to book.
  • Regulatory moat (partial, leaking): USCG captain licensing, vessel documentation, and liability permits. Building these takes 18+ months and real operational experience. However, this moat is only defensible if we *visibly own it*—competitors can route around unenforced advantages via off-platform lead capture.

BSSD (the referral outreach engine) targets a distribution moat through exclusive partnerships and consistent brand presence across 12 city-specific properties. Currently: all 12 Queenof-cities sites are indexed but flagged noindex in CloudFront (dist E176JRMB92GPAJ), which was a deliberate moat-kill decision at some prior point. The moat was built (proprietary referral templates, city-specific landing pages, accumulated organic authority) and then switched off.

Dragon Bodyguards is structured as a network-moat play (reputation, crew density, escrow trust) but is hemorrhaging leads through mailto: links in the site footer—violating the distribution moat rule that channels must be proprietary or exclusive. Every click that could have landed in SMS, a booking form, or a crewed intake funnel instead bounces to the user's email client.

Tenant Portal (3028 51st St) already has a workflow moat: tenants pay rent, check balances, and request receipts through an embedded system. It's at ceiling for that property (high switching cost, daily use).

Technical Decisions: Building Toward 4+ Moats

1. Queenof-cities Re-enablement (Distribution Moat Infrastructure)

The 12 city sites (sailjada.com, queenoflosangeles.com, queenofsan diego.com, etc.) live in ~/jada-ops/sites/queenof-cities/ with a single CloudFront distribution (E176JRMB92GPAJ). They were indexed, then noindex was added. To reactivate the distribution moat:

  • Remove noindex headers from CloudFront cache behavior rules (via Terraform or AWS console).
  • Validate route structure: each city site should have /crew, /book, and /faq paths that internally route to JADA crew rosters and booking flows—locking users into JADA's property.
  • Enforce a Vary: Accept-Language, User-Agent header to fragment the SEO signal (prevent Google from treating all 12 sites as one), and use Route53 to geo-route: US west coast → JADA, US east → Queen of New York (future), etc.
  • Command to validate current state: aws cloudfront get-distribution-config --id E176JRMB92GPAJ | jq '.DistributionConfig.DefaultCacheBehavior'

2. Dragon Bodyguards: Closing the Lead Leak (Distribution → Workflow)

Dragon Bodyguards (dragonbodyguards.com, CF dist E10WJ716X823DQ) currently routes "book" clicks to mailto:. This breaks both distribution (leads escape the system) and network (no reputation trail). The fix:

  • Replace footer mailto: link with an SMS intake form that captures name, event date, guest count, and security profile (wedding, corporate, high-net-worth). Route via the shared JADA SMS utility (sending from 619-986-7344 or a dedicated 619-GUARD-### number).
  • Store intake submissions in a DynamoDB table: dragon-bodyguards-intakes (partitioned by `contact_phone` + timestamp). This creates the network-moat audit trail: reputation, response time, crew assignment patterns.
  • Command to validate SMS routing: send-sms "Test intake submission" 619-986-7344 (from jada-ops SMS utility).

3. Data Moat: Consolidated Crew & Charter Registry

Currently, crew availability, guest histories, and past charter data live in three places: DynamoDB (JADA charter bookings), Google Calendar (JADA Internal, crew muster), and CSV files in jada-ops. This is a leaking data moat—no single source of truth for "which crew have the most guest repeat bookings" or "what weather patterns correlate with high referral conversion."

The fix uses a deterministic nightly sync:

  • At 06:00 UTC, a Lambda function (jada-data-sync) fetches crew availability from Google Calendar, guest contact data from passengers/contacts.csv, and charter revenue from DynamoDB.
  • Normalizes into a single DynamoDB table: jada-charter-events (sk = YYYY-MM-DD, attributes = crew_roster, guest_list, weather, revenue, referral_source, repeat_guest_flag).
  • Stores read-only snapshots in S3: s3://jada-data-lake/charter-events/YYYY/MM/DD/charter_DATETIME.json for audit and BI tools.

4. Workflow Moat: Crew Dispatch as a Deterministic State Machine

The crew dispatch flow (captain → preferred mate → roster fallback) is documented in jada-crew-dispatch-cascade but currently lives in brain-based approval. To embed crew deeper into the workflow and make it irreplaceable:

  • Encode dispatch logic into a Step Functions state machine: jada-crew-dispatch-sm. Input = {charter_id, departure_datetime}. Outputs crew assignments 72 hours before departure, enforcing quiet hours (Travis Neel: never 17:00–08:00) and fatigue rules (no captain > 16h in 48h window).
  • Crew receive SMS magic links (short-lived, SMS-only distribution) to confirm or reject—creating a friction-lock: crew must opt-in to this specific charter through the system, no casual email forwarding.
  • Each crew member's acceptance/rejection, last-minute substitutions, and muster compliance feeds back into the charter-events DynamoDB table, compounding the data moat.

Infrastructure Patterns & Why They Matter

SMS-Primary for Moat Friction: Email is forwardable and low-friction; SMS is device-specific and creates a switching cost. By routing crew confirmation, guest confirmations, and intake submissions through SMS (not email), we embed customers and staff deeper into the JADA operational flow—increasing the workflow moat.

One-Way Data Flow (EC2 → DynamoDB → S3): The estate-git system (~/jada-estate/ on Mac → bare remote on Lightsail) ensures a single source of truth for operational decisions, but the actual moat data (charter history, crew assignments) flows downstream into DynamoDB and S3 only. This prevents accidentally leaking moat data through a misconfigured backup or accidental sync reversal.

CloudFront Caching Without Invalidation for Moat-Critical Paths: Queenof-cities landing pages are marked CachingDisabled for /g/* (guest booking) and /print/* (trip sheets), ensuring real-time crew availability and pricing reflect in the booking flow. Non-critical marketing pages cache for 7 days, reducing costs while keeping the moat (live crew, live pricing) fresh.

Key Decisions

  • Why not rebuild Queenof-cities from scratch? The 12 sites already have organic authority and backlinks. Re-enabling noindex unlocks those moats. Building new domains costs 12-24 months of authority rebuilding.
  • Why DynamoDB + S3 for data, not a traditional data warehouse? DynamoDB supports deterministic TTL-based cleanup (charter data older than 3 years auto-deletes, keeping moat data compact) and fine-grained access control per crew member. S3 snapshots are audit-immutable, satisfying compliance for liability tracking.
  • Why SMS over email for crew dispatch? Crew can't easily forward SMS to a competitor; every assignment pins them to the JADA system. Email forwarding (or "just text my mate") leaks the dispatch logic and crew network.

What's Next

The unblock path is auth-first: enable IAM/Secrets Manager access to cloudfront, dynamodb, and route53 on the deployment EC2 instance, then sequentially:

  1. Re-enable Queenof-cities noindex → index via CloudFront (1 day, 0 risk).
  2. Replace Dragon Bodyguards mailto: with SMS intake form, wire to dragon-bodyguards-intakes DynamoDB table (2 days, low risk).
  3. Build jada-crew-dispatch-sm state machine and wire to crew SMS (4 days, requires quiet-hours and fatigue-rule testing).
  4. Launch nightly jada-data-sync Lambda to consolidate crew, guest, and charter data into single source of truth (2 days).

Once complete, JADA will hold 4+ durable moats: physical (yacht), regulatory (licensing + permits), distribution (Queenof-cities + SMS crew dispatch), and data (charter-events lake). That's the durability threshold.