Why would you consider microservices if you are only 12 developers?
I’m in a team of 4 and the few API’s we expose would be considered microservices. We did that because it was easiest and fastest for us to build and maintain and the features we provide were all quite distinct.
Suppose, for example, your webapp backend has to do some very expensive ML GPU processing for 1% of your incoming traffic. If you deploy your backend as a monolith, every single one of your backend nodes has to be an expensive GPU node, and as your normal traffic increases, you have to scale using GPU nodes regardless of whether you actually need more GPU compute power for your ML traffic.
If you instead deploy the ML logic as a separate service, it can be hosted on GPU nodes, while the rest of your logic is hosted on much cheaper regular compute nodes, and both can be scaled separately.
Availability is another good example. Suppose you have some API endpoints that are both far more compute intensive than the rest of your app, but also less essential. If you deploy these as a separate service, a traffic surge to the expensive endpoints will slow them down due to resource starvation (at least until autoscaling catches up), but the rest of your app will be unaffected.
Real-world monoliths often do have some supporting services or partner services that they interact with. That doesn't mean you need a "micro-service architecture" in order to scale your workload.
In fact, this is what you usually do with "worker" nodes that do background jobs.
And you can always have feature flags/environment variables to disable everything you don't need in a given cluster.
And that I think how you should approach micro services, to solve an organizational problem, not use it for solving a technical problem.