The Monorepo for Solo Developers: A Studio Operating System

I don't run a development shop. I run a multi-product studio. The distinction matters because my output isn't measured in billable hours or tickets closed, but in the number of durable, profitable systems I can keep in the air at once.

When you are a solo builder using AI as your team, your biggest constraint isn't compute or capital—it's context. Every time you switch between different repositories, different deployment pipelines, and different dependency versions, you pay a cognitive tax. For a long time, I paid that tax. I learned the hard way that managing a dozen separate repositories for a dozen small products is a recipe for stagnation.

If you want to scale your output without scaling your headcount, you need a monorepo for solo developer operations. This isn't about following a trend; it's about architecting a system that allows you to ship today and maintain tomorrow without losing your mind.

The Cost of Fragmentation

In the early days of my studio, I followed the standard advice: one repo per project. It felt clean. But as the portfolio grew to five, then eight products, the cracks appeared.

I would find a bug in my authentication logic in Product A, fix it, and then realize Product B, C, and D were all vulnerable to the same issue. I had to manually port the fix across four different environments. I spent more time updating Node versions and fixing broken GitHub Actions than I did building features.

Fragmentation is the enemy of the solo operator. When your code is scattered, your AI agents are blind. They can only see the narrow slice of the project you've pointed them at. By consolidating into a single repository, you provide a unified context that makes agentic engineering actually viable.

The Studio Monorepo Architecture

I use a structure built on PNPM workspaces and Turborepo. It’s not the only way to do it, but it’s the one that has survived my production requirements. The goal is to treat your products as thin wrappers around a core set of shared engines.

The Shared Package Layer

In a proper monorepo for solo developer workflows, the \packages/\ directory is where the real value lives. I break mine down into specific domains:

• \packages/ui\: A unified design system. When I want to add a new button style or a navigation pattern, I do it once. Every product in the studio gets the update instantly.

• \packages/db\: A shared Prisma or Drizzle schema. Even if products use different databases, the patterns for connecting, migrating, and querying remain consistent.

• \packages/ai\: This is where VERA, my custom agent orchestration layer, lives. By centralizing my AI prompts, MCP servers, and tool definitions, I can give every product in my portfolio the same level of intelligence without rewriting the integration code.

The Apps Layer

Your actual products live in \apps/\. Because the heavy lifting is done in the shared packages, spinning up a new MVP becomes a matter of hours, not days. You import your UI, your auth, and your AI logic, and you focus entirely on the unique value proposition of that specific tool.

Tooling for the Solo Architect

I don't invest in complex tooling for the sake of it. I invest in tools that reduce the friction of shipping.

Turborepo

Turborepo is the orchestrator. It understands the dependency graph of my studio. If I change a utility function in \packages/utils\, Turborepo knows exactly which apps need to be rebuilt and which ones can stay cached. This is how I keep my CI/CD pipelines under three minutes, even with multiple products in the mix.

PNPM Workspaces

I moved away from NPM and Yarn years ago. PNPM’s content-addressable storage means that if ten of my products use the same version of a library, it’s only stored once on my machine. It’s fast, it’s efficient, and it handles workspace dependencies without the ghosting issues common in other managers.

Agentic Engineering in the Monorepo

This is where the strategy pays off. When I’m working with Claude or my internal agents, I’m not just asking them to write a function. I’m asking them to operate within the context of the entire studio.

Because the UI components and API patterns are standardized across the monorepo, the AI doesn't have to guess how I want things built. It looks at the existing apps, sees the patterns in the shared packages, and generates code that is 90% ready for production on the first pass.

Working in public has shown me that most people treat AI as a better autocomplete. In a monorepo, AI becomes a junior architect. It understands the system because the system is visible, centralized, and consistent.

When to Consolidate

You might think you’re "just a developer" with one or two projects and don't need this. You're wrong. The best time to move to a monorepo was when you started your second project. The second best time is today.

If you find yourself copying and pasting code between folders, or if you dread opening an old project because you know the dependencies are out of date, you are the target audience for a monorepo for solo developer setup.

Shipping Today

Building a multi-product studio is a marathon of consistency. You cannot afford to be slowed down by your own infrastructure. A monorepo isn't just a folder structure; it's a commitment to a unified way of building. It allows you to focus on the craft of the product rather than the plumbing of the repository.

I’ve spent years refining this setup across music businesses, logistics operations, and now software. The medium changes, but the need for a centralized operating system does not.

If you're ready to stop managing repos and start building a portfolio, start by consolidating your core logic. The speed you gain will be the difference between a hobby and a studio.

Happy to talk.

Justin Tsugranes