J
TL;DR : you need a shared integration environment
There are a lot of moving parts here, so giving explicit advice on what to do might be quite impossible. When you're faced with a complex situation, the trick is to know how to think, rather than what to do.
This question will invite the criticism of generating opinionated answers, because there are many ways to provide a more stable development environment. A guiding principle may be however the idea of https://12factor.net/dev-prod-parity from the https://12factor.net app which states:
Keep development, staging, and production as similar as possible
If the development teams on the various components follow independent release cycles (which they should, if the application is properly composed of microservices), then it would make sense to have a shared integration environment to develop against. This could be hosted remotely and provide a single environment for all developers.
Of course, this means you need to have access to that shared environment, and hence the network, so you will lose some offline capabilities. However, it seems like the only way to maintain offline development capability would be upgrading each individual member's hardware, so I'm guessing that you will be forced one way or another to do development connected to the network. If you're going to have network access, you might as well have access to a shared integration environment.
The tricky part of course is ensuring that this environment stays current and correct. This is where the practice of continuous delivery comes in. If you have, say, 4 teams working on 4 separate components of the application, then changes to each of those 4 components should be properly versioned and continuously delivered to the shared environment.
A good starting discussion for for developing robust APIs, I found is https://increment.com/apis/web-api-versioning/ .