An interview with Bartek Sądel, Engineering Manager & Monorepo Expert at VirtusLab
Monorepo keeps coming up in conversations about large-scale software architecture. For some organizations, it’s a way to bring order to a growing ecosystem of applications. For others, it raises a lot of concerns. We spoke with Bartek Sądel - an expert who works with enterprise monorepos about how this approach works in practice, what questions companies ask, and what the real benefits and challenges are.
If you put yourself in the shoes of a decision maker in a large organization who has to decide whether to move to a monorepo, what would they want to know first?
Bartek: That’s a good question. I think someone in that position would want to understand the whole picture: how the transition works, what the organization actually gains, what the risks are, and what kind of impact it will have.
It’s often a bit of a political decision as well. The person making it usually has to justify it later to the board or other stakeholders. So they need solid arguments - what the company gains, what the real effects are, and what potential risks need to be considered.
Security often comes up as one of the strongest arguments for a monorepo. Why is that?
Bartek: Security is definitely one of the big reasons organizations start thinking about it.
If a vulnerability appears somewhere, it’s much easier to identify what exactly we’re using across the organization, because everything lives in one place.
And the same goes for updating dependencies. If suddenly a major vulnerability in some library is discovered and everyone is talking about it, in a monorepo, you often fix it in one place and update all applications at once.
From a security perspective, that’s a huge advantage. Instead of trying to track down thirty people responsible for thirty different applications, you have one repository and one process.
People also sometimes ask whether a monorepo can reduce costs. Does it actually make a difference financially?
Bartek: Yes, although the impact isn’t always in the most obvious place.
One area is infrastructure. In a monorepo, multiple teams and applications can share the same build and testing infrastructure instead of maintaining many separate environments that are sometimes idle but still generate costs.
But the financial impact goes beyond infrastructure. A lot of it comes from efficiency. When you improve developer experience across a monorepo, those improvements apply to everyone working in that repository. Saving even a few minutes in the development workflow - multiplied across hundreds or thousands of engineers - quickly adds up.
So the savings often come from several places at once: better infrastructure utilization, easier dependency management, and improved productivity across the organization.
What about things like standardization or reporting across the organization - does monorepo help there as well?
Bartek: Yes, because it’s much easier to enforce standards. When everything is in one repository, you can introduce a single project structure, a single way of building software, and consistent reporting. That makes it easier to generate reports or analyze what’s happening across the organization.
This becomes especially important in larger companies.
A good example is SBOM - Software Bill of Materials. It’s basically a list of all components used in your software. The concept originally comes from manufacturing, where a bill of materials lists every part that goes into a product - every bolt in a car.
Now, similar requirements are appearing in software as well, often because of regulations. If everything is in one repository, generating that kind of report becomes much easier.
How does monorepo affect developers themselves? Does it actually improve developer experience?
Bartek: Yes, very much so. And as I mentioned earlier, when we talked about costs, improvements in developer experience can have a really big impact at scale.
But beyond that, monorepo also makes everyday development workflows much more consistent. Everyone works in the same environment, uses the same tooling, and follows the same patterns.
That makes it much easier to introduce improvements. If we optimize something in the development workflow or improve the tooling, it immediately benefits everyone working in the repository.
In a multi-repo setup, every team might have its own way of building, testing, and organizing code. In a monorepo, you’re improving one shared ecosystem, which makes those improvements much easier to introduce and scale.
What’s the biggest challenge organizations face when running a large monorepo?
Bartek: One thing is very important: a large monorepo cannot really work without a team responsible for developer experience.
If you try to run a monorepo without people who take care of tooling, build systems, and workflows, problems start appearing very quickly. Instead of speeding things up, development will actually become slower.
Developers sometimes seem skeptical about monorepo. Where does that resistance come from?
Bartek: Developers often notice the restrictions first.
Monorepo introduces certain standards, rules, and processes. On one hand, those standards are exactly what allow us to optimize things and improve efficiency.
But on the other hand, developers usually value autonomy. They like deciding on their own tools and workflows. Monorepo limits that freedom to some extent, and that’s why you sometimes see resistance. But once those standards are in place, the whole organization benefits - teams spend less time dealing with tooling and more time building things that actually matter.
