Decision Log

Firebase provides the best multi-tenant isolation model via per-tenant Firestore collections or projects, tight integration with Firebase Auth for tenant-scoped access, and native Cloud Functions for Jimmy AI jobs. Per-tenant Firebase projects are a viable scale path. Supabase was too relational for the dynamic, document-first content model.

Most customers are Swiss SMEs. GDPR + nFADP compliance is simplified with Swiss data residency. Zürich node provides lowest latency for CH customers. Customer can explicitly opt into another region post-onboarding.

Tight coupling between shared types, UI components and apps makes a monorepo the most productive choice. pnpm workspaces are simple and fast. Turborepo can be added later if build caching becomes a bottleneck. Separate repos would create unnecessary friction during early platform build.

brandgym.dev must be the strategic, operative and documentation center — operator-level. Studio is customer-facing and tenant-scoped. Mixing them would either compromise security (tenant sees operator data) or usability (operator drowns in per-tenant UI). Clean separation = cleaner product.

hub/hub-2 are Supabase-based, light-themed, with hardcoded German labels and tenant-specific patterns. Building v3 on top of them would require removing more than adding. Clean break = faster iteration. Pattern absorption: sidebar structure, nav grouping, and billing page concepts from hub are already absorbed into brandgym-dev.

A neutral, generic tenant proves the platform is truly generic — not secretly tuned for one customer type. Real customer data must never appear in tests. BrandGym Demo Tenant is professional, plausible, and tests all modules cleanly.

Per-tenant Jimmy allows persona customization, tenant-scoped data access, and isolated memory. Platform-level Jimmy surface in brandgym.dev gives operators visibility into all tenant Jimmy activity. No cross-tenant data leakage possible by design.

Hardcodes make the platform impossible to generalize. One hardcoded customer name = the platform is secretly a custom app. Data-driven UI is the only path to real multi-tenancy and scalable onboarding. Seed data (TypeScript constants today) maps exactly to Firestore documents later — no refactor needed.

BrandGym needs one central product truth to decide what becomes config, pattern, extension, new module or integration. If planning objects live per tenant, the platform loses comparability, governance and reuse. Platform-scoped planning keeps strategy coherent.

Leading with Agentic makes the product feel bigger, more modern and more category-defining. BrandGym remains present as the framing brand layer, but not the loudest first-screen message.

The metaphor is strongest when it signals performance, conditioning and coaching without collapsing into bodybuilder kitsch. This keeps BrandGym premium, serious and distinct.

BrandGym is a product where behavior, scope, migration safety and tenant isolation matter as much as build success. Delivery must therefore validate not just code, but operational safety and agent logic.

Real coordination requires distinct personal, project and tenant contexts with clean handoffs and memory scopes. This layered architecture is a stronger product category than generic “AI for teams”.

A personal front layer reduces UX fragmentation, keeps accountability clear and avoids visible bot-zoo confusion while still allowing rich internal orchestration behind the scenes.

Real multi-person, multi-project coordination needs stable scoped memory, confidence handling and explicit visibility states beyond ordinary conversational context.

Projects need their own stable memory and coordination logic. Treating Grace as a true project intelligence layer avoids context collapse and improves handoffs.

Once agentic work becomes real operational work, governance has to be productized, inspectable and consistently enforced.

Tenant-wide coherence needs a distinct layer above project and personal scopes. Emily provides that without exploding the visible UX roster.

Real business support requires richer operational identity than simple tenant metadata. Company Brain enables consistent tone, policy, region and scope behavior.

Runtime-first modeling keeps product, data and orchestration aligned and makes implementation safer and more composable.

Track-based execution preserves continuity and makes larger work visible, governable and auditable across multiple runs and humans.

Browser execution is too important and too risky to remain an implicit helper capability. It needs explicit runtime, policy and evidence treatment.

Agentic work crosses multiple domains of risk and authority. A multidimensional matrix is required for real operational safety.

True per-company database isolation provides the clearest security and trust model for a product handling sensitive operational context and credentials.

Trustworthy automation requires reviewable and machine-usable records of what happened, why it happened and what changed.

The product is meant to reduce friction in real work, not perform friendliness. Structured directness is more useful and aligns with user preferences.

The doc landscape is large enough that explicit truth ordering is needed to avoid mixing old and new product reality.

The platform needs one productized internal place where runtime states are visible, governable and actionable.

Once runtime work touches sensitive tenants, browser sessions and credentials, coarse admin models become unsafe and operationally messy.

Good operations depend on the right attention reaching the right role at the right time. That requires explicit alerting design.

A coherent runtime UI map is required to turn the canonical runtime architecture into actual operator usability.