Monorepo or separate repos

Recommendation: use one monorepo.

Eight engineers, three tightly coupled codebases, and a shared API client is close to the ideal case for a monorepo. The API client is the dependency that ties the web and mobile apps together. With separate repos, every change to it means publishing a package, bumping versions in two other repos, and coordinating releases. Versions drift, and bugs show up only after integration. In a monorepo, one pull request can change the client and update both consumers, and CI proves they all still work together. At this team size, that saved coordination matters far more than the tooling cost.

Risk 1: CI slows down and becomes fragile as the repo grows. Every commit could trigger builds and tests for all three projects, which wastes time and makes unrelated failures block people.

Mitigations:

• Use a workspace tool with affected-only builds and caching (Nx, Turborepo, or Bazel if you need it later) so a web-only change doesn't rebuild mobile.
• Use path-based CI triggers and remote caching.
• Track CI duration as a metric and set a budget, such as under 10 minutes for a typical PR.

Risk 2: Unclear boundaries and ownership lead to tangled code and accidental coupling. When everything is importable from everywhere, the web app can start reaching into mobile internals, or the shared client can pick up app-specific logic. A single main branch also means one broken merge affects everyone.

Mitigations:

• Define clear package boundaries (apps/web, apps/mobile, packages/api-client) and enforce them with lint rules, such as Nx module boundaries or ESLint import restrictions.
• Use CODEOWNERS so changes to the shared client require review from the right people.
• Protect main with required CI checks and a merge queue, and keep PRs small.
• Give the shared client a stable public interface, with internals not importable by apps.

One caveat: mobile release cycles (app store review, users on old versions) differ from web deploys. A monorepo doesn't prevent this, but keep the API client backward compatible, and version and release the apps independently from the same repo.

Recommendation: Use a Monorepo

For a team of eight engineers, a monorepo is the best choice. At this scale, the biggest bottleneck to velocity is the "dependency hell" of updating the shared API client, publishing it, and bumping versions across separate repos. A monorepo allows for atomic commits—an engineer can update the API client and implement the changes in both the web and mobile apps in a single Pull Request—which drastically speeds up development and prevents version mismatches.

Here are the two biggest risks of choosing a monorepo and how to reduce them:

1. Risk: Slow and Expensive CI/CD Pipelines Because mobile builds (especially iOS and Android) are notoriously slow, running the entire test and build suite for all projects on every commit will quickly grind development to a halt. A one-line CSS change in the web app should not trigger a 30-minute mobile build.

• How to reduce it: Implement a modern monorepo build system like Nx or Turborepo from day one. These tools map the dependency graph of your repo and allow you to configure your CI to run only the tests and builds affected by a specific Pull Request. They also provide remote caching, so no two engineers (or the CI) ever build or test the same unchanged code twice.

2. Risk: Tangled Dependencies (Spaghetti Code) Because all the code lives in the same place, it is very easy for an engineer to accidentally (or lazily) import web-specific code into the mobile app, or app-specific logic into the shared API client. Over time, this creates tight coupling that makes the apps impossible to untangle.

• How to reduce it: Enforce strict module boundaries using automated linting rules (e.g., ESLint’s no-restricted-imports or Nx’s enforce-module-boundaries plugin). Configure these rules so that the web and mobile directories are strictly forbidden from importing from one another, and can only import from the shared-api directory. If an engineer violates this, the build should fail immediately. Additionally, use a CODEOWNERS file to require sign-off from senior team members whenever the shared API client is modified.

Use one monorepo for the web app, mobile app, and shared API client.

For a team of eight, the coordination benefits likely outweigh the overhead: shared code changes can be made atomically, API client updates can be tested against both apps together, and tooling/CI standards stay consistent.

Recommendation: Monorepo

A possible structure:

repo/
  apps/
    web/
    mobile/
  packages/
    api-client/
    shared-types/
    ui-or-utils/
  tooling/

This works especially well if the web and mobile apps frequently depend on the same API client or shared types.

Biggest risks and mitigations

1. Risk: Slow CI and noisy builds

If every change triggers tests and builds for every app, the repo will become frustrating quickly.

Reduce it by:

• Using affected-project builds/tests, e.g. Nx, Turborepo, Bazel, or custom path-based CI.
• Caching dependencies, build artifacts, and test results.
• Requiring only relevant checks for each pull request.
• Splitting CI into fast required checks and slower scheduled/full validation jobs.

Example:

• API client change → test API client, web integration, mobile integration.
• Web-only change → test/build web only.
• Mobile-only change → test/build mobile only.

2. Risk: Accidental coupling between apps

A monorepo can make it too easy for the web app, mobile app, and shared client to depend on each other in messy ways.

Reduce it by:

• Defining clear package boundaries.
• Enforcing dependency rules with linting or repo tooling.
• Keeping shared code intentionally small and stable.
• Versioning or changelogging important internal packages, even inside the monorepo.
• Assigning ownership for key packages like the API client.

For example, apps/web and apps/mobile should depend on packages/api-client, but the API client should not depend on either app.

Bottom line

Use a monorepo because the team is small and the products share an API client. It will make cross-app changes easier and reduce version drift. Just invest early in selective CI and clear package boundaries so the repo does not become slow or tightly coupled.

Use one monorepo.

With eight people and a client shared by both apps, the cost of coordinating versions and breaking changes across repos is higher than the cost of one repo. Atomic changes to the client and both consumers are the main win.

Risk 1: CI gets slow and noisy. A change in one app rebuilds and retests everything, so feedback and deploys drag. Reduce it with a task graph (Nx, Turborepo, or Bazel), remote caching, and CI that only builds and tests affected packages. Keep web, mobile, and the client as separate packages with their own pipelines where the graphs allow.

Risk 2: Boundaries dissolve. Shared code and cross-imports turn the repo into one ball of mud, and ownership of the client gets fuzzy. Reduce it with explicit package boundaries and dependency constraints (lint or the build tool should fail on illegal imports), CODEOWNERS per package, and a stable public surface on the API client with a changelog so web and mobile cannot reach into its internals.