The Rule
Every client gets their own n8n instance. They see their app’s nightly build status and the full app process workflows on THEIR instance. This educates clients on SDLC and eliminates uncertainty about what’s happening with their project.
BUT: We are careful not to expose trade secrets. The client sees the RESULTS of our process, not the process itself.
Two-Tier n8n Architecture
Internal n8n (PLATFORM_OWNER — QC1)
The full pipeline. Trade secret. Never exposed:
- Agent orchestration (Granville → Maya → Nikki → Gary)
- Ephemeral swarm provisioning
- Code review automation
- Build farm management
- Cost optimization
- Model routing (Clara intelligence)
Client n8n (SITE_OWNER — per-client instance)
Curated view. Shows enough to build trust, not enough to replicate:
- Nightly build status (started → building → succeeded/failed)
- TestFlight delivery confirmations
- Feature progress (story completed, PR merged)
- Deployment pipeline (dev → staging → production)
- Test results summary (passed/failed, not the test code)
- Sprint progress dashboard
Analogy
Kitchen (internal) vs Dining Room (client). They see the beautiful plate arrive, not the 15 cooks and recipes.
Maps To
PLATFORM_OWNER vs SITE_OWNER — already in the architecture. Internal n8n = platform infrastructure. Client n8n = site visibility.
Why: Clients paying $4,200+ need confidence their money is being well spent. Seeing automated workflows running every night = trust. Seeing 53 agents and ephemeral swarms = giving away the competitive advantage.
How to apply: Every client-facing workflow must be designed with “what should the client see?” filter. Internal workflows push EVENTS to client n8n via webhook. Client n8n never queries internal systems directly.