Oh man, this sounds like a dealbreaker, but thanks for sharing your approach nonetheless!
If people are churning after like 1-2 years, they never get to experience the long term pain themselves, and new hires will lobby for rewrites anyways. Since individual apps are rather small, rewrites service-by-service should be straightforward and manageable.
Ancient knowledge would be helpful here, but most teams simply don’t have „real“ seniors around. Therefore simple advice from my end:
1. keep the database stupid and sane. Postgres usually has everything needed for nearly every usecase in a good enough and battleground way. Don’t overdo complex join queries in hot code paths.
2. use a mature, slow-changing (as in: no breaking changes yearly) tech stack, that is powerful out of the box. When you need to use several infrastructure crudges, the tech isn’t powerful enough. I recommend Elixir, Go or even JVM-flavors, these will carry you far.
3. Monolith it is, fullstack. Every service/frontend you split apart might become easier in isolation, but you pile up significant overhead and complexity in terms of global monitoring/orchestration/dependencies/testability/debugging. Elixir/Phoenix, PHP/Laravel, … are fine choices that also have straightforward scaling options and cover everything you need probably.
4. minimize/eliminate usage of JS wherever possible. Aside from infrastructure providers/external APIs, this is the biggest source of maintenance issues. Also SPAs are rarely worth it, there still is a boring way of progressive enhancement that just works.