Interesting indeed. While still doing two services we manage local development using gems in ruby which allow us to seamlessly include the other service’s code as a library and we write unit tests using that integration. The two binaries are built as two gems with versions and tested locally. When it comes to deploy we deploy both at the same time. We get many advantages mentioned here while the services operate independently.
We have a very similar story at my org. We run around 100 RDS aurora clusters and switched to graviton. I'm surprised to see 35% gains here, we saw more like 10-15%. But since amazon natively supports mysql on aurora we didn't have to worry about compatibility. Our main highlight was the way we wrote our infra as code where we made switching instances types or service we use fairly simple task, so we have switched instance types a couple of times in past and could easily make dev use t3s.
Getting on cloud is a trap and not the usual we deploy on the servers and we live situation. Give weight to write some good code to manage your infra and able to adopt optimizations as they occur. It will ramp up in expense soon otherwise.
This is a tough balance. I agree that code quality has much less importance when it comes to MVP and startups. The key point differentiator for a good engineer/lead is to be acutely aware of all the compromises and techdebt that being piled upon the product. Understand the effects of each and add them to the backlog so that as soon as an issue crops up from them these tasks from backlog are prioritized.
Another important aspect is to continually architect a solution that involves components that can be broken off once we want to improve them or no longer use them.
