Every six months, someone on Twitter reignites the monorepo versus polyrepo war and I lose another year of my life watching people argue about something that has no universal answer.
"Monorepos are the future! Google uses one!" Yeah, Google also built their own version control system, their own build system, and employs thousands of infrastructure engineers to make it work. You have seven developers and a GitHub org.
"Polyrepos give you true independence!" Cool, enjoy maintaining 47 separate CI pipelines, coordinating releases across 12 repos, and spending half your sprint debugging version mismatches between packages that should have been updated together.
It depends on your team, as boring as that answer is. For a small team with tightly coupled services and shared libraries, I would use a monorepo. Turborepo has made the tooling much better. Its cache cuts build time a lot, and it handles the dependency graph and incremental builds, with remote caching too.
Polyrepo makes sense with a large team, independent services, and different deployment cadences. Each team owns its repository, CI, and deployment, which gives them clear boundaries.
I think most teams that choose polyrepo do it because they do not want to invest in monorepo tooling. And I have seen teams pick monorepo because it was in fashion and pay for the tooling later. Neither reason is good enough.
The tooling question is what actually matters. Lerna moved to the Nx team in 2022 and now runs on top of Nx; for a new project, I would go straight to Nx or Turborepo. Nx is powerful but complex. Turborepo hits the sweet spot for most teams. Pick your tool based on your actual needs.
And stop comparing your setup to FAANG companies. They have different problems than you do.