The monorepo gives us one place to trace a change from product code to deployment. It also makes cross-product imports convenient. Four ownership layers keep separate products from merging into one codebase.
Products own customer behavior
Verachi and Midflight are peer products. Each owns its routes, interface, data model, integrations, migrations, and release evidence. Product code cannot import code from another product.
Similar screens can still have different rules. A decision record and an incident investigation can both contain comments. Their permissions, failure behavior, and retention rules remain product-specific.
Four layers define repository ownership
Each top-level layer owns a specific class of decisions:
- Products: Customer behavior, domain data, policy, and releases
- Framework: Product-neutral Software as a Service contracts and reusable runtime mechanics
- Platform: Shared cluster prerequisites and infrastructure
- Tools: Workspace checks and guarded orchestration
The owner decides where a change belongs. The number of callers does not decide ownership.
Shared code needs two production consumers
Similar files are not enough reason to extract a package. Shared code needs two production consumers with matching failure behavior. The package also needs a neutral name, an explicit contract, independent tests, and one owner.
The framework can own an accessible button or a tenant-context primitive. Verachi defines a decision. Midflight defines execution evidence. Those definitions stay in product code.
Shared foundations reduce agent token use
Saving tokens with a SaaS template describes the cost of rebuilding the same SaaS foundation for every product. Authentication, tenant isolation, billing, email, migrations, logging, and feature flags consume prompts before product work starts.
Mooomooo applies that idea through framework/saas. An
agent can inspect one reviewed contract instead of designing the
same capability again for Verachi and Midflight. This reduces
repeated context and implementation tokens. It also keeps security
checks and failure behavior under one owner.
The repository has no percentage target for token savings. The practical measure is narrower: fewer prompts spent recreating framework code, and more prompts spent on product-specific work.
Nx checks the boundaries
Nx runs the cross-project task graph. Root Bun commands delegate to Nx. Package commands stay local to their project. Tags record each project’s scope, type, runtime, and visibility.
Boundary checks reject imports that violate ownership. The graph still allows product builds to depend on framework builds.
External mutations use explicit commands
Checks and builds can run across affected projects. Database changes, releases, Terraform applies, and other external mutations use named targets. Those targets are uncached and serial.
An affected-project command can discover several products. It cannot mutate all of their databases or production environments.
Ownership decides the path of a change
A change can cross several layers while each decision stays with its owner. Product policy stays in the product. Reusable mechanics enter the framework after a second consumer proves the shared contract. Platform and tooling changes follow their own review and release paths.