Yeah, zero doubt investing in robust, automated E2E tests in that situation is key. I’d also add: - Get the “change engine” running smoothly (productive and re

Yeah, zero doubt investing in robust, automated E2E tests in that situation is key. I’d also add: - Get the “change engine” running smoothly (productive and reliable local dev environment, reasonably fast/reliable build/deploy jobs) - Get people understanding, documenting, and teaching others the high level functionality and architecture If you skip those steps, and hop straight to new features, you’re just asking for regressions, outages, poor architecture/design decisions, and just a very slow pace of work. But invest in those 3 up front and you can get to a point where you’re evolving the product well, with few regressions, at a good pace, even without vets to teach the newbies.