50 engineers. Over 1,000 repositories. A one-line change that took almost a day to ship.
Years ago, getting up to speed on a new engineering system, I found an architecture that made sense on paper: microservices, clean separation, each external integration its own service. Over a thousand of them, each a few lines of code.
But when something changed, a developer had to touch dozens of repositories, run test suites across all of them, and coordinate releases. For one line. Almost a day, every time. That cost never showed up as a line item. It showed up as slipped releases, as engineers who stopped attempting small improvements because the overhead wasn’t worth it, as a roadmap that quietly shrank to fit the friction.
The architecture wasn’t wrong. The platform wasn’t there to support it.
I’ve also seen the opposite. A monorepo that many engineers dismiss before the conversation starts. It outperformed every multi-repo setup I’d seen. Staged releases, strong anomaly detection, fast rollbacks. Developers could trace dependencies end-to-end. When something broke, anyone could see it and fix it. Ownership became cultural, not by policy, but by visibility.
Velocity went up. Incidents went down. Engineers trusted the system.
Here’s what both taught me: microservices don’t fail because they’re microservices, and monorepos don’t succeed because they’re monorepos.
A monorepo without the tooling to support it becomes a deployment bottleneck. Microservices without a platform to orchestrate them become a coordination tax. The deciding factor was never the diagram. It was whether the platform underneath made the chosen structure cheap to operate.
The architecture is a choice. Platform Engineering is what determines whether that choice works.
Too many engineering teams debate the wrong thing: mono versus micro, monorepo versus multi-repo. It feels like a strategic decision because it’s the one drawn on the whiteboard. But the structure you pick is far less decisive than the capabilities underneath it: the build pipeline, the observability, the rollback path, the golden routes that make the right thing the easy thing.
The teams that win this aren’t the ones with the cleanest architecture diagram. They’re the ones who invested in the platform underneath it. Where has that bet paid off for you, or where are you still paying the tax?
Pick the structure that fits your problem. Then build the platform that makes it work.