Monorepo or Many Repos for a Small Laravel Team

Laravel projects grow extra code over time: a shared package, an internal admin tool, maybe a second app that reuses the first one’s domain logic. At some point you have to decide whether everything lives in one repository or gets split into several.

Start with one repo#

For a small team, one repository is the right default for a simple reason: every change is atomic. When the app and its shared package live together, a rename lands in a single commit, CI runs once, and there is no version matrix to keep in your head. Composer makes this comfortable with path repositories:

"repositories": [
  { "type": "path", "url": "packages/billing" }
],
"require": {
  "acme/billing": "*"
}

The package sits in packages/billing inside the same repo, and Composer symlinks it in. You get the directory structure of a split without any of the coordination cost.

When splitting starts to make sense#

Split a repo only when one of these becomes true:

• A package is genuinely reused across projects with different release cadences, and tagging it independently matters.
• Different people should have different access rights - a contractor on the marketing site should not see billing code.
• CI time is dominated by unrelated code, and path-scoped pipelines cannot fix it.

“One day this might be an open-source package” is not on the list. That day can be handled when it arrives.

Splitting later, keeping history#

When the day comes, you do not have to lose history. git subtree split extracts a directory into its own branch with every commit that touched it, ready to push into a fresh repository:

git subtree split --prefix=packages/billing -b billing-history

That is a much better story than the usual alternative of planning repository topology up front for a future that may never happen. It is also worth contrasting with submodules, which solve a different problem - vendoring an outside dependency with its own history - and bring real day-to-day friction.

The short version: one repo until something concrete hurts, path repositories for internal packages, subtree split when a package earns its independence. Repository topology is a scaling decision, and small teams scale by not making it early.