Lets Check If It Works
The moment your software has its first user is the moment you have to reduce breaking changes to the minimum and keep the system up for as long as possible.
There are a few strategies to deal with this like, working in small increments, versioning the system for gradual adoption and deprecation, creating various intermediate environments between development and production, testing the quality of the code, testing the final integration, monitoring the servers capacity, etc. These are among the most common practices that are implemented in all software projects indifferent of the team size.
The only problem with all these strategies is that they deal with the code after it was deployed and none of them deal with improving and ensuring the code quality while writing the code which is where the most leverage is.
To have the ability to reproduce as close as possible all the context in which your piece of software will be part of is an underrated method by which you can ensure all the software is working while you are writing it. Spinning up the Project A to work on it while also having the ability to spin up the Project B and Project C to check how these services interact with new changes while you are making them is the best way to see how a local change changes the whole. You will be able to experience first hand when you are making breaking changes or degrading the service quality.
As side-effect, you will also absorb a lot of contextual knowledge on how different projects are interconnected with each other and be able to notice sub-optimal implementations and have the insights to propose system wide improvements no one else in the team has.
“But I am not an X or Y developer” is not an acceptable excuse. All projects should have a one line command that installs the dependencies and starts the projects. Even more so in the world of containers we are currently living in. If the project requires more than that, ask your team for help. If it is not possible to setup the project even with the help of your team then you and your team have a bigger, more urgent problem than coding a new improvement.
In recent days, this article went viral again. It highlights perfectly how not being able to reproduce locally the production environment as close as possible degrades the entire system and making it unmaintainable in the long run. Fake it or not, the article serves as a cautionary tale for everybody.
In order to ensure a healthy software system over a long period of time it has to be easy to maintain. In order to be easily maintainable, a system has to be easy to operate. To be easy to operate a system has to be easy to setup. If it easy to setup, it means you can make as many changes as you want in an environment as close as possible to the one your users will be in and at the same time be as far as possible from it.