For a long time, I believed monorepos were overkill. They seemed like something only “big companies” used because they had too much code and not enough structure. So, like most developers early on, I split everything into separate repositories: frontend in one, backend in another, and shared code in a “cleanly isolated” place.

It felt organised at first. However, over time, that sense of clarity gradually eroded.

💥 The Problem Begins Quietly

Initially, everything seemed smooth. Each repository was independent, each service isolated, and there was no visible coupling between systems. This gave a strong sense of clean architecture.

But problems didn’t appear immediately. They started quietly. A shared function might be updated in one place, but another repository wouldn’t reflect that change. Types slowly diverged, and imports that once worked silently stopped. Eventually, bugs only appeared in production, not during development.

What once felt like a clean separation slowly transformed into multiple systems that no longer fully agreed with each other.

🧠 The Real Issue Was Never Separation

Initially, I thought I was practising proper modular design by splitting everything into different repositories. I believed I was reducing complexity.

However, the real problem was that I wasn’t separating concerns; I was separating context.

In real applications, much logic is naturally shared. Validation rules, API contracts, UI components, utility functions, and types aren’t independent pieces. They’re part of the same system.

When this shared logic is split across multiple repositories, complexity doesn’t disappear; it simply shifts into synchronisation problems between systems.

⚙️ The Shift: Monorepo Thinking

Switching to a monorepo didn’t feel like a tooling decision at first. It felt like a shift in how I thought about code structure.

Rather than maintaining separate repositories for frontend, backend and shared logic, everything consolidated into a single structured system. Logically, applications and packages remain distinct but reside within a unified codebase.

This structure shifts your perspective on code relationships. Instead of managing multiple independent systems, you now oversee a connected one.

⚡ Turborepo’s Arrival

Monorepos alone aren’t sufficient for efficient problem-solving. Without appropriate tooling, they can become cumbersome and slow.

Turborepo revolutionised this.

The first major improvement is intelligent caching. Rather than rebuilding everything repeatedly, only the system’s changing components are rebuilt.

The second improvement is pipeline execution. Tasks like build, test and lint run in a structured dependency order automatically, eliminating manual management.

The third improvement is dependency graph awareness. The system comprehends package connections, eliminating the need for manual coordination.

This transforms the monorepo from feeling heavy to efficient.

🧠 The Mental Shift

The most significant change isn’t technical, but mental.

Initially, the mindset was to split code to reduce complexity, assuming separation inherently simplifies system management.

However, working with monorepos shifts this perspective. Instead of splitting code to reduce complexity, you group it to control it.

Monorepos don’t eliminate complexity; they make it visible, structured and easier to manage as a single system.

🚀 What Actually Improved

Once everything migrated to a monorepo, the improvements became evident in daily development.

Shared code became genuinely shared rather than duplicated, improving type safety as everything existed in a single synchronised system. Testing became more consistent due to a single source of truth, leading to a more predictable and less fragmented developer experience.

Instead of switching between multiple repositories, everything resided in one place, creating a more connected workflow.

⚠️ Monorepos Aren’t a Magic Solution

While powerful, monorepos aren’t magic and come with their own challenges. Initial setup becomes more complex, CI/CD pipelines require advanced features and discipline is needed to maintain the structure. Tooling also plays a crucial role in ensuring efficiency.

Without proper structure, a monorepo can become just as messy as multiple separate repositories.

🧩 When Monorepos Make Sense

Monorepos are suitable when multiple applications share logic, components are reused across projects, strict type consistency is essential and scalability is a priority.

However, if systems are truly independent and don’t share meaningful logic, a monorepo may introduce unnecessary overhead rather than solving problems.

🔮 Final Thought

I didn’t adopt monorepos because they were trendy or popular. I switched because multiple repositories conflicted with my natural system thinking.

Once you view software as a connected system rather than isolated parts, monorepos cease feeling like an option and become a structure that finally makes sense.