Monorepo

A single repository holding multiple projects or packages, for example the web app, API and shared libraries together.

A monorepo keeps everything in one place: frontend, API, shared UI components, internal packages, infrastructure config. The alternative is many repos with versioned packages published between them. Both work; the difference shows up in the size of your changes and the speed of your CI.

Why it matters to an indie builder: a small team shipping a product wins on coordination. In a monorepo, a breaking change to a shared type is one pull request that updates every consumer at once, and the review shows the full blast radius. No publishing packages, no version drift between five repos you alone maintain. This is why Vercel, Google and most framework teams run monorepos, and why tooling grew around the pattern.

A concrete example: your SaaS has a Next.js marketing site, an API, and a React component library used by both. The invoice type changes. In a polyrepo world: bump the shared package, publish, update two consuming repos, fix what broke in each. Monorepo: one PR edits the type and both call sites, CI runs all affected test suites (Turborepo or Nx compute which projects are affected and run only those), and you merge once. Twenty minutes instead of an afternoon.

Common mistakes: no internal boundaries (a monorepo without package structure becomes a big ball of code; keep clean packages with their own package.json and tests), slow CI on every commit (fixed by affected-only builds and remote caching, which Turborepo and Nx provide out of the box), and version-control pain on large binaries (keep assets out, or use Git LFS). A pragmatic middle ground if you are starting solo: monorepo from day one, but with package boundaries drawn as if you would split them later. You probably will not, and that is fine.

If your stack is JavaScript or TypeScript, start with pnpm workspaces and add Turborepo when CI gets slow. Other ecosystems have equivalents, and the build-tool blocks here list the current standard set. The one-sentence rule: monorepo for everything one team ships together, split repositories only when ownership genuinely separates.