The Problem I Didn’t Notice Until I Worked Across Multiple Repositories
I thought managing more repositories meant writing more code. Instead, it taught me that keeping everything in sync was the hardest part
When I first joined the team, development felt simple.
Everyone had a clear area of responsibility.
Frontend developers worked on the UI repository.
Backend developers worked on the API repository.
Cloud engineers and backend developers maintained the AWS repository, which contained the code for Lambda functions, SQS queues, S3 buckets, SNS topics, and other cloud resources.
Database administrators managed the database repository.
There was also a local development setup repository that contained the Docker configuration, startup scripts, and everything needed to run the system locally.
At the time, I only had to focus on the repository assigned to me. I rarely thought about how all of these repositories worked together.
Then the previous maintainer left the company.
As a result, I inherited responsibility for several repositories that I had never worked on before. My day-to-day work was no longer limited to a single codebase. A single feature could now require changes across the UI, API, AWS, database, and local development setup repositories.
Initially, I thought the biggest challenge would be the increased workload.
I was wrong.
Our sprint planning still considered the additional responsibilities. The amount of work was manageable.
The real challenge was something much less obvious.
It was coordinating changes across multiple repositories.
When you’re working in a single repository, life is relatively simple. Every branch represents a complete snapshot of the project. Feature branches, releases, and bug fixes all live in one place. As long as your branch is up to date, you can be confident that you’re working on the latest version of the application.
That assumption disappears once your project is split into multiple repositories.
Each repository has its own branches, commit history, release schedule, and pull requests. A feature is no longer represented by a single branch. Instead, it becomes a collection of related branches spread across different repositories.
Imagine implementing one feature that requires changes in five repositories:
UI
API
AWS
Database
Local development setup
Now imagine your team supports both a monthly release and a quarterly release.
One feature can easily become ten active branches.
Those branches are not independent. They all represent the same feature, so they have to stay aligned throughout development.
Every time the develop branch changes, you need to make sure the relevant feature branches are updated.
Every bug fix needs to be applied consistently.
Every merge needs to happen at the appropriate time.
Miss just one branch, and you’ve created an inconsistent version of the system.
The complexity doesn’t stop there.
Every repository needs its own pull request.
Instead of opening one pull request for a feature, you might create five. If the work also needs to be released through multiple release branches, that number can easily double.
Now imagine being the reviewer.
Instead of reviewing one pull request, you need to review several related pull requests and understand how they fit together. A single feature is scattered across multiple repositories, so understanding the complete implementation requires jumping between them.
If changes are requested during the review, the process starts again. Update the affected branches, push the commits, and wait for another review cycle.
Testing introduces another layer of complexity.
For a peer tester to reproduce the feature locally, they need to check out the correct branches from every repository involved. If even one repository is using the wrong branch or is missing the latest commits, they are no longer testing the same version that the developer implemented.
At that point, it becomes difficult to determine whether a failure is caused by a bug in the code or simply because one repository is out of sync.
That was the moment everything clicked.
The problem was never the additional responsibilities.
The problem was coordination.
Every new repository introduced another version that had to stay synchronized with all the others. As the number of repositories increased, so did the effort required to keep everything aligned.
Writing the feature was often the easiest part.
Keeping every repository synchronized throughout development, code review, and testing was the real challenge.
That realization changed how I viewed software engineering. I stopped thinking only about writing features and started paying more attention to developer experience. Reducing coordination overhead through automation, reproducible development environments, and standardized workflows can sometimes deliver more value than the feature itself because it makes every future change easier to build, review, and test.