LODGEST Developmental Path for Scale

One system: capture every event, consolidate one truth, serve every decision.

The blueprint for turning Lodgest's existing automation into a tech-forward moat — accurate, compounding data that makes the company's decisions for it.

BLUEPRINT v1.0·2026-06-25·Sub-20 properties · scaling·Tap any node for detail
You've solved capture. The keystone you're missing is consolidation — one queryable source of truth the dashboards read from instead of pulling live from Notion.
31
Parser channels live
12
AI projects in system
0
n8n workflows yet
1
Source of truth needed
The Architecture
Three planes, one spine

Events flow top to bottom: external systems are captured into staging, consolidated into a single Postgres source of truth, then served to people and agents. A foundation of protocol + version control governs all of it; the data that accumulates is the moat.

Live today Partial / needs work Missing — the gap New build
01 Capture Get every event out of every system  ·  strong today
↓ ↓ ↓
02 Consolidate Normalize · reconcile · store one truth  ·  the keystone
↓ ↓ ↓
03 Serve Dashboards · command center · site · alerts  ·  partly built

▣ Foundation & Governance

The operating system underneath every project. Already mature — GitHub is the one piece to add.
_system protocol v1.1.0 State-File truth model Project-Manager protocol Credentials vault (Keychain) Registries + GitHub version control

◆ The Moat

Tooling is replaceable. What compounds and can't be copied: your accurate, normalized, time-series data — and the owner retention it deepens. Low churn is already your moat; this work makes it systematic instead of dependent on you grinding all hours.
Owner retention — your moat today Proprietary normalized data Per-property / owner unit economics 4.9★ · 412-review Superhost profile Accurate, automated owner reporting Pricing intelligence Direct-booking channel (later)
The Path
Model-first, then scale

Sequenced for where you are now: nail the model on the current portfolio first — owner reporting, maintenance, guest-insight — and park marketing + the direct platform until the model's proven (low churn means acquisition isn't today's constraint). Every early phase turns service quality that runs on you grinding all hours into a repeatable system. Don't build everything at once; prove one painful process end to end first. Tap a phase to see what it lights up.

Tap a phase above to highlight the components it activates.
The fork shrank — here's what's left

The store engine is settled: SQLite file + Turso mirror.

The source of truth is a local SQLite file — the engine your Revenue Foundation already reconciles to the cent — mirrored read-only to Turso Cloud (your account already exists). The heavy hosting fork from the earlier plan dissolves: there's no Postgres server to place on Railway or DigitalOcean. Notion is demoted to SOPs + human docs. What's left is small and reversible.

Where the single writer runs decide at Phase 0
The n8n ingestion + publish job needs a home — a Mac cron, a small always-on box, or CI (a scheduled GitHub Action). Reversible; start wherever's quickest. n8n already runs, so this is mostly "point it at the build."
Postgres — the graduation trigger, not now
Move the operational store to Postgres only when you hit genuine concurrent multi-writer load or a true transactional app backend (owner portal). Until then it's added cost and ops for nothing. The SQLite file migrates cleanly when that day comes.