I would think the biggest and probably most obvious one would be dependency management, or, rather, making sure that one microservice is not dependent on another.
A close second would be: how to organize code? By that I mean, say you're using a language like PHP. Do you put all your microservices in one .php file? If so, you run the risk of undetected code errors in one place affecting a completely unrelated microservice. Would it be better to organize the code into separate .php files? There's also the front end for calling microservices. How do you organize that? Do you, for example, use separate tiny javascript files to define your front-end microservice calls? Or all in one file? I suspect this is one will be a somewhat opinionated answer, that is, each person will have a strong opinion as to what the best organization method is. I'll stay out of that discussion.
In addition to the points already made, monitoring becomes more complicated and each service having its own database means that the consistency of data has to be considered and managed. There's tooling to help with these things, but it's still more complicated than a monolith. The advice to start off building a monolith makes a lot of sense, especially if you approach it with an eye toward how you would break it apart eventually, if the project matures.
Vishwa Bhat
Technology Enthusiast
Two things.