Monorepo Strategy for Multi-App Ecosystems: How Blossend Ships 6 Platforms

Running six platforms as a solo founder requires ruthless code reuse. Our monorepo strategy lets OpenMyPro, Noizz.io, Blossend.com, and three internal tools share authentication, UI components, and utility libraries while deploying independently. Here is the architecture that makes this possible.

Why Monorepo Over Polyrepo

The alternative to a monorepo is six separate repositories with shared code published as npm packages. I tried this approach for two months and abandoned it. The overhead of versioning, publishing, and syncing shared packages across six repos consumed more time than the features I was building. Every shared component change required a package publish, version bump, and update in all consuming repos.

A monorepo eliminates this entirely. Shared code changes are immediately available to all applications. TypeScript project references ensure type safety across app boundaries. A single git history provides full context for any change across the ecosystem.

Repository Structure

Our monorepo follows a simple structure. The apps directory contains each application: apps/openmypro, apps/noizz, apps/blossend, and three internal tools. The packages directory contains shared code: packages/ui for shared components, packages/lib for shared utilities, packages/config for shared TypeScript and ESLint configurations.

Each application in apps is a standalone Next.js project with its own next.config.ts, package.json, and deployment configuration. Applications import from packages using TypeScript path aliases. There is no build step for shared packages — TypeScript compiles them inline with the consuming application.

Shared UI Components

The packages/ui library contains components used across multiple platforms: buttons, cards, forms, navigation elements, and layout primitives. These components use Tailwind CSS classes and accept customization through props, not style overrides. This ensures visual consistency while allowing each platform to express its own brand identity.

The design system is intentionally small — about 25 components. Each component is used by at least two applications. We resist the urge to premature-abstract. A component does not graduate to the shared library until it is copy-pasted between apps for the second time. This prevents the shared library from becoming a dumping ground for single-use components.

Independent Deployments

Vercel's multi-project support is the key enabler for independent deployments. Each application in our monorepo is connected to a separate Vercel project. When code changes in apps/openmypro, only the OpenMyPro project rebuilds and deploys. Changes in packages/ui trigger rebuilds for all applications that import from it.

Vercel detects which files changed in each commit and intelligently decides which projects need redeployment. A change to a blog post data file only triggers the portfolio site rebuild. A change to the shared auth utility triggers rebuilds for all six applications. This selective deployment keeps build times low and prevents unnecessary redeployments.

Shared Authentication Library

Our most valuable shared library is the authentication module. It wraps Supabase Auth with our multi-app session management, role-based access control, and middleware configuration. Every application imports the same auth functions, ensuring consistent authentication behavior across the ecosystem.

When we added provider role verification to the auth middleware, the change was made once in packages/lib/auth and automatically applied to all six applications on their next deployment. In a polyrepo setup, this would have required six separate code changes, six PRs, and six deployments — any one of which could be forgotten.

Dependency Management

All applications share root-level dependencies for core packages: React, Next.js, TypeScript, and Tailwind CSS. This ensures version consistency across the ecosystem. Application-specific dependencies like Stripe (only used by OpenMyPro) live in the application's own package.json.

We update core dependencies monthly by bumping versions in the root package.json and running the full test suite across all applications. This prevents version drift where one app is on React 18 while another is on React 19 — a situation that makes shared components impossible.

Scaling Considerations

The monorepo approach works well up to about 10 applications and 50 developers in our estimation. Beyond that, build times and git clone sizes become prohibitive. For Blossend's six-platform, one-developer setup, it is ideal. The entire repository is under 500MB, git operations are instantaneous, and full rebuilds take under 3 minutes.

If we grow to the point where the monorepo becomes unwieldy, we would likely split into a federated architecture with Turborepo managing dependency graphs across repos. But that is a problem for a 50-person engineering team, not a solo founder.