Monorepo As Operational Platform

Summary

The monorepo gives LKCI one place to evolve operational data, automation, review, integrations, UI, infrastructure, and documentation together.

Problem

Small-company operations rarely split cleanly by product boundary. A marketing workflow may need lakehouse facts, a scheduling job, email delivery, review state, and an operator console. Splitting those too early would create coordination cost before the domain shape is stable.

Principle

Keep conceptually separate responsibilities in one repo until the boundaries are mature enough to split physically. Use package structure, tests, and hooks to enforce the separation that deployment topology does not yet enforce.

Platform Shape

The repo contains apps, services, libraries, integrations, pipelines, jobs, infra, operations, and docs. That lets a single change update a data contract, service behavior, job entrypoint, UI surface, guardrail, and explanatory doc in one reviewable unit.

The important part is not that everything is physically together. The important part is that capability boundaries are explicit inside the monorepo. Future splits become realistic because jobs, services, integrations, and app adapters already communicate through visible contracts.

Source Evidence

• docs/reference/architecture.md
• docs/public/platform-journey-strategy.md

Tradeoffs

The monorepo increases the need for architectural discipline. Without package rules and docs, it can become a dumping ground. With them, it becomes a useful control surface for platform evolution.

Related Reading

• docs/engineering/architecture/platform-layers.md
• docs/engineering/architecture/designing-for-future-separation.md