Monorepo as Operating System

The monorepo at Total Ventures is the single source of truth for all product code, infrastructure, and shared utilities, allowing me to operate a multi-brand studio with the efficiency of a single-product team.

What it is

This is a single Git repository housing all of Total Ventures' digital products and their supporting services. It's built on a pnpm workspace, which manages dependencies efficiently by symlinking packages, and uses Turbo for build orchestration and caching. Within this structure, each product like Total Formula 1, Pregnancy Power Hour, or Inky exists as a distinct application. Alongside these, I maintain a set of shared packages for UI components, utility functions, API clients, and infrastructure definitions. This setup means that a common `tsconfig.json` or `eslint` configuration applies across the entire studio, enforced by the root.

Why I do it this way

The core driver for this approach is operational efficiency for a solo builder running multiple products. I gain consistency in tooling, linting, testing, and deployment patterns across everything I ship. This significantly reduces the cognitive load of context switching between disparate projects. When I need to launch a new product, the foundational infrastructure is already in place, reducing setup time from weeks to a single day. Updates to shared dependencies or underlying infrastructure are propagated across all projects simultaneously, minimizing maintenance overhead. This structure is also particularly effective for Agent-First Development, as agents can leverage standardized patterns and shared code, reducing the surface area for errors. It also makes my review process for agent-generated code more deterministic, aligning with how I use Claude Code as the Engineer.

How it works in practice

When I bootstrap a new brand, I use a custom template within the monorepo. This template pulls in pre-configured Next.js app structures, shared UI components, and API client setups for services like Resend or Stripe. For CI/CD, Vercel is configured to deploy specific applications within the monorepo based on changes detected in their respective directories, ensuring only relevant services rebuild. Firebase functions and other backend services are managed similarly. All critical shared infrastructure—database schemas in Firebase Firestore, authentication via Firebase Auth, payment processing through Stripe, email delivery with Resend, and banking integrations with Mercury—are defined and versioned within this single repository. This centralized approach, combined with a commitment to Document While Shipping, ensures that the operating model remains clear and functional as the studio grows.

Where this breaks down

While highly effective, the monorepo approach isn't without its challenges. The initial setup requires a significant investment to configure pnpm, Turbo, and the CI/CD pipelines correctly. Build times can become a concern as the number of projects and shared dependencies grows, though Turbo's caching mitigates this considerably. Dependency management, while simplified by pnpm's hoisting, still demands careful attention to avoid version conflicts across many packages. Security is another consideration; a vulnerability in a broadly used shared package could impact all products simultaneously, requiring diligent auditing. For a solo operator, the learning curve of understanding the entire dependency graph is manageable, but it's a factor to acknowledge.