Maybe it’s just my bias from engineering @ Meta, but I still believe monorepos > polyrepos, even now, building Structured Labs. Startups move fast. You realize you need to refactor a core API, touch three services, update the frontend. In a monorep it’s one atomic commit, one code review, one deploy In a polyrepo setup you’re opening 3 PRs, coordinating versions, juggling deploys across repos. Early-stage, that kind of friction kills momentum. People reach for polyrepos early bc they want modularity. Isolation feels clean. But at early stage, that’s the wrong constraint. You want services and data models evolving together. You want to move quickly without ceremony. You want the ability to tear up an entire subsystem and rebuild it without dealing with versioning hell. Monorepos let you keep logical boundaries (dirs, owners, tooling rules) without physically fragmenting your systems too soon. Structure without the overhead. Curious where others land on this — are you team monorepo or polyrepo, and why? Would love to hear how it’s worked (or not) for you.
All code should live within one function in one file
It's a continuum at the end of the day. Early on, go monorepo and ship fast. Once you have a 200+ person engineering team, you need to start distributing services and specializing teams. That is how you maintain agility at scale. There are good patterns to navigate the evolution from monorepo to polyrepo as you grow.
I would say it depends on the situation. There should be a logical separation (or lack thereof) of components. If you're in a polyrepo environment, is one person regularly needing to make changes to multiple repos to complete their tasks? Thats not great, but the solution might not necessarily be monorepo. It's a symptom that could indicate poor project planning, poor separation of team responsibilities, or even just unclean code.
Probably better for ai driven code creation workflows too!
I agree, in the same way that separating functionality into microservices introduces complexity, and “premature optimization is the root of all evil”. I prefer to implement the simplest solution that works for the current requirements. Especially in the age of AI, refactorings are relatively easy now. The only benefit I see of separating things like that are to reduce conflict between people stepping on each others’ toes. Microservices are tech debt, except in extreme cases.
Absolutely agree. I started doing this a few startups ago, and now I can't imagine wasting the time, energy and brainpower doing it the other way.
Hard agree for early stage startups. Once the org grows dramatically the decision is more a function of eng culture than it is a technical one. How do you want teams to interact? How coupled do you want them to be? Those types of questions end up driving the decision.
Agree 💯 If mono repo works well for Meta and Google (even with their own tooling) why would you do it differently for your (tiny in comparison) codebase? You can (and probably should) still deploy different services from that one repo (if you want the isolation/have different scaling needs). I use a single repo even with different languages in it e.g. Python + JS, much faster to evolve the codebase having everything together.
Depends on the logic really. If for example the functionality includes a Python wrapper for the Linear API, so the boundaries to the rest of the code are clear and natural, might as well make that a separate repo (and open source it while you're at it :) ) Within the core application, where there are few if any natural boundaries to begin with, I agree that monorepos are the way to go, at least until the code settles down and those natural components emerge.
Co-Founder & CTO at TextQL | Full Self Driving for Data Analysis
1moIsn't FB a polyrepo? Last I was there they had fbcode, www, configurator, chef,... Although every single one is one of the largest codebases in the world by itself