What working on a large open-source monorepo taught me

Since late 2023 I have been working on Ever Teams and Ever Gauzy, two open-source platforms built by Ever Technologies: work and time tracking on one side, a full business-management suite (ERP, CRM, HRM…) on the other. Both live in large monorepos with web, desktop, mobile and server apps side by side.

Here is what that environment taught me, beyond any single framework.

Read the boundaries before the code

In a monorepo, the folder structure is the architecture. Before touching a feature I now look for:

• apps/ — what actually ships (web, mobile, desktop, server);
• packages/ — what is shared (UI kit, types, API clients, config);
• the dependency direction — apps depend on packages, never the other way round.

Breaking that direction ("just import this from the web app") is how a monorepo slowly becomes one big ball of code.

Shared types are the real API contract

When the web app, the mobile app and the server share one TypeScript package of types, a change to a DTO breaks the build everywhere it matters, before review. It's the cheapest integration test you will ever get. The flip side: a "small" change in a shared package needs the same care as a public API change.

Small pull requests travel faster across time zones

With reviewers in other countries, a PR waits hours between rounds. What helped me most:

1. One concern per PR. A refactor and a feature in the same PR doubles the review time.
2. Say what you tested — the platform, the steps, a screenshot or a short recording.
3. Leave the codebase a bit cleaner, but in a separate commit so reviewers can skip it.

Respect the build graph

Monorepo tools (Turbo, Nx…) cache builds by dependency graph. If you understand that graph, you can run only what your change affects instead of the whole repository — on your machine and in CI. Learning those commands early saved me more time than any editor shortcut.

Open source changes how you write

Code in a public repository will be read by strangers, sometimes years later. I write more explicit names, fewer clever tricks, and comments that explain why. That habit followed me into private client projects — and they're better for it.

For developers in Africa

Contributing to open source is one of the most direct ways to show your work to the world: the code, the reviews and the discussions are public. You don't need permission to start — pick an issue labelled good first issue, read the contribution guide, and open a small, well-described PR.