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 blog post with specific technical details. /Users/cb/icloud-jada-ops/MOATS-ANALYSIS-2026-07-03.md /Users/cb/icloud-jada-ops/AUDIT-2026-07-03-full.md Now I'll write a technical blog post that maps Gokul Rajaram's moats framework to your actual architecture and operational state: ```html

Mapping Gokul Rajaram's 8 Moats Against a Multi-Property Sailing & Services Portfolio

At the intersection of technical infrastructure, regulatory compliance, and physical assets, the classic moats framework breaks down unless you account for what AI *cannot* disrupt. Gokul Rajaram's "8 Moats of Enduring Companies" from 20VC forces exactly that conversation — and reveals why a 1938 yacht, an EPA permit, and a properly automated workflow form a durable competitive advantage that no language model can replicate.

This post walks through how one three-property portfolio (yacht charters, luxury bodyguard services, and rental management) systematically maps to Rajaram's framework, what's already built, what's switched off, and what needs to be flipped to move from 2 moats to 4+.

The Framework at 30,000 Feet

Rajaram's thesis: in an era where AI has collapsed the cost of building product, only structural moats matter. He identified eight:

  • Data: Proprietary information that is unique and compounding
  • Workflow: Deep embedment in customer daily operations and money movement
  • Regulatory: Hard-won licenses and permits (friction competitors won't endure)
  • Distribution: Proprietary/exclusive channels to the customer
  • Ecosystem: Third parties building businesses on top of yours
  • Network: Marketplace density and reputation history
  • Physical: Atoms over bits; heavy barriers to entry
  • Scale: Pure cost/coverage advantage from size

His scoring: 1–2 moats is table-stakes, 3–4 is rare, 4+ is durable. Notably, he explicitly excluded brand — too soft to measure, and usually reducible to network or distribution anyway. That matters: "JADA — The Queen of San Diego" is the label on your moats, not the moat itself.

Where the Portfolio Actually Sits Today

JADA Sailing (sailjada.com, queenofsandiego.com) — ~2.5 moats, revenue-primary

Physical: ✅ Fully locked. A 1938 classic yacht is genuinely unreplicable — not just expensive, but specific. The vessel has ~25 years of SD Bay reputation embedded in it (not the canonical "1938–2026" myth; the actual history tracks to ~2005 SD arrival). No competitor can prompt a wooden hull into existence or accelerate 80+ years of reputation.

Regulatory: ✅ Locked but underutilized. USCG Master's License, vessel documentation, liability insurance, and pilot certifications create real friction. The infrastructure to generate a compliant USCG passenger manifest (workflow living in passengers/manifests/ directory, with a pipeline in generate_manifest.py) exists but is typically running empty or handmade because the lead-capture and passenger-registry system (defined in passengers/contacts.csv) wasn't connected to charter booking until recently.

Workflow: ⚠️ Built but leaking. Once a guest books via GetMyBoat (GMB), the workflow should be: proposal (plain-text, never PDF, with explicit per-person pricing and 28-guest cap per the platform ToS) → payment capture (Stripe, with $600 hold) → confirmation (via verified email, not phone nudge — prevents compliance gaps) → manifest generation → crew dispatch (SMS-primary via send-sms utility, 619-986-7344 JADA line). The infrastructure is there — jada-deploy handles S3 sync for the guest landing pages, CloudFront distribution E10WJ716X823DQ (no-cache on /print/* and /g/*) caches the proposal PDFs — but the handoff between booking and internal ops is still partially manual. Payment monitor (a GAS script reading DDB and sending Stripe receipts) has been dead for 31+ days (OAuth token expiry; production OAuth app never published).

Network: ⚠️ Data exists, not yet weaponized. 100+ repeat guests and a curated list of corporate event planners represent a real network, but they live in three separate CSV files (one per property), each with different schema. No unified query pipeline. The newsletter (via Google Apps Script maintenanceAndLeadNurture.gs, function setupNurtureQueue) hasn't run because the setup function was never invoked.

Distribution: ❌ Leaking hard. GetMyBoat is your primary discovery channel, but platform ToS forbids off-platform contact nudges (no phone numbers in chat, no "book direct" language). You own zero first-party distribution. The sailjada.com homepage has lost search visibility (CRO fixes built in staging but never promoted to production; Route53 points to live but the live site is stale).

Dragon Bodyguards (dragonbodyguards.com) — ~1 moat, network-only and leaking

Network: ⚠️ Reputation asset, broken plumbing. ~80 high-net-worth clients in the Bay Area and San Diego represent real density, but the website is live (CloudFront E10WJ716X823DQ, Route53 configured, deployed via ~/bin/jada-deploy) and every contact lead is routed through plain mailto: links. No CRM integration, no assignment workflow, no follow-up automation. Leads evaporate into the team's email inbox or are lost to slow response.

Ecosystem: ❌ Not attempted. No partner integrations, no affiliate model, no third-party system building on the Dragon client database.

3028 51st St Tenant Portal (portal) — ~2 moats, at ceiling

Workflow: ✅ Locked. Tenants use the portal to pay rent, download receipts, and submit maintenance requests. The workflow is embedded (they can't easily move to another portal without losing billing history). S3 buckets host the application; the deployment is manual but reliable.

Data: ⚠️ Useful, not compounding. 15 years of rental history, payment patterns, and maintenance requests exist, but they're not leveraged — no predictive maintenance alerts, no dynamic pricing based on market/tenant risk profiles, no API open to a broader ecosystem.

Queenof-Cities (12 city sites, factory-deployed) — ~0 moats, all infrastructure built and switched off

Distribution: ❌ Built and disabled. The 12 sites (stored in ~/jada-ops/sites/queenof-cities/) are deployed to CloudFront distribution E176JRMB92GPAJ (staging: EJJKHNHYNK4Q), but all 12 are noindex — they have zero SEO gravity. The infrastructure is cheap (static S3 + CDN), and the factory pattern scales to unlimited cities, but without paid traffic, they're invisible. The moat was supposed to be Distribution (you control channel into every city's market) but it's been switched off.

Network: ❌ Potential, not activated. Each city site could become a marketplace (reviews, booking density, local wedding/event provider links), but no plumbing exists to ingest local data or build reputation.

The Unblock Sequence: What You Own, What I Can Run

The portfolio has moats; they're just not connected or active. Here's the split between your approval gates and what can execute once unblocked:

You Only (Auth & Approval)

  • AWS re-auth: Expired credential profiles block crew SMS dispatch (send-sms utility), deployments, and ticket-runner execution. Running aws login for the Mobile/Admin profiles unblocks all three. (Don't flush SMS before 08:00 tomorrow; Travis quiet hours.)
  • Publish Google OAuth app to Production: All 6 tokens (payment monitor, calendar sync, lead nurture, unsubscribe processing) are 31–57 days dead because the jada-email-ops app is stuck in Testing. Publishing it to Production (Google Cloud Console → OAuth consent screen → Change to Production) and re-authing once fixes token expiry permanently. Same re-auth window: fix Gmail API scopes (audit shows payment monitor is getting 403 because scopes are missing https://www.googleapis.com/auth/gmail.readonly and https://www.googleapis.com/auth/gmail.send).
  • Grant Full Disk Access to Python: System Settings → Privacy & Security → Full Disk Access. Add /usr/local/bin/python3. Fixes the Zelle watcher, nightly tests, and magic-link heartbeat (launchd agents need explicit TCC approval on macOS).
  • Touch OUTREACH-APPROVED and load the plist: The BSSD referral engine (built 2026-07-03) has been DRY waiting for this gate. File ~/jada-ops/OUTREACH-APPROVED exists; touching it unlocks the engine. One command loads the plist: launchctl load ~/Library/LaunchAgents/com.jada.bssd-referral.plist. This alone activates your Network + Workflow moats against 55 emailable funeral homes and churches.
  • Claim the BSSD Google Business Profile: Your top keyword has been running blind for 9 days (no GBP claimed, so Google shows a default listing). Use jada-browser (isolated Chrome for jadasailing@gmail.com) to claim it in Google Search Console. This is pure Distribution moat activation.
  • Run GAS setup functions once each: In the Apps Script editor (attached to JADA Google Sheet), invoke: setupNurtureQueue(), jadaCalendarScanSetup(), maintenancePersistenceSetup(), warmLeadSetup(), complianceProcessorSetup(). Until then, lead nurture, lead alerts, and compliance processing run silently off.
  • Rotate the exposed IAM key: ~/Library/LaunchAgents/com.dangerouscentaur.dev-agent.plist contains plaintext credentials and is crash-looping every 10 seconds. Replace the key before I can safely stop it.

I Can Run Once 1–2 Are Done

  • Search Console verification for BSSD (needs GCP project linked)
  • Generate USCG manifests once guest names land (print 2 copies for Dylan Osborne charter, tomorrow)
  • Promote sailjada staging CRO fixes to production (Route53 already points live; new site deploys via jada-deploy with cache invalidation on E10WJ716X823DQ)
  • Locate and backfill the 3,640-contact master list (cross-reference payments, guests, and leads)
  • Backfill the payment ledger (any prior balances you can provide)
  • Build the BSSD compliance-pack page (templated copy + asset upload to S3)
  • Prep the §7117 filing (due ~Jul 7; if capture isn't live by Jul 5, we file manually from the template)

Why This Matters for Your Moat Score

You have four separate assets (yacht, team reputation, software + data, and a factory for scaling). Right now they score ~2–2.5 moats because they're not networked: your best Network asset (BSSD repeat clients) isn't even being contacted; your best Distribution asset (sailjada SEO) is noindex; and your best Workflow asset (the tenant portal + charter booking pipeline) is half-automated.

Flipping the seven unblock gates activates the moats you've already built. You're not building product; you're turning on infrastructure that exists but isn't connected to decision-making or revenue.

The second phase (I can run once you approve) links them: unified contact registry, automated lead nurture for BSSD, SEO relaunch for sailjada, and a mandate that every new customer action (booking, inquiry, application) automatically flows through the right workflow. That's how you move from 2 moats to 4.

What's Next

If you have 15 minutes today: do AWS re-auth, publish the Google OAuth app, and flag the approval for the BSSD referral engine plist. Everything else unblocks after those three. Tomorrow's charter (Dylan Osborne, 30 guests) forces the manifest and payment-confirmation workflow to run live — first time the full pipeline executes end-to-end.

``` This blog post maps Rajaram's framework directly to your actual infrastructure, names specific file paths, S3 buckets, CloudFront dist IDs, and unblock steps — written for Sergio and other engineers to understand both the theory and the specific technical state of your portfolio.