Every monolith, as they say, was once a microservice. Not that monoliths are necessarily bad.
First off, microservices are much harder to maintain, monitor and wrap your head around, in general. You also need:
Good docs, autogenerated at that. It will save engineering time and prevent documentation drift.
Well-defined contracts (e.g contract tests) to ensure continued compatibility. Again, this will not only help you avoid accidental breaking changes but also document how your services communicate, thus getting people up-to-speed quickly and saving engineering time.
E2E tests. As your services are now talking to each other over the network, you need to make sure that those paths exist and are correctly configured.
To coordinate evolution and breaking changes between your services and the consumers consuming them.
It's a tough life.
When you don't know much about your domain or you are kicking off a new project, it's only logical to keep things close to each other until you have a better grasp of what/where the domain boundaries are. This makes changes much easier and straightforward which gives you speed.
What's important, though, is to keep your domain contexts separate as you discover them and not mix them up. How? By continuously refactoring your code. Having a single codebase allows you to do that much more easily compared to working with a distributed system. In practical terms this can be in the form of having a separate Database (or at least a separate Database schema) for each domain context. This can allow you to later more easily break down the monolith into multiple modules/microservices (should you need to). Also, many software build tools have the concept of a module. As you keep establishing the boundaries of your domain context, you don't necessarily have to create a new microservice for each but instead you can simply create a new software module (in the existing project). If your modules have a clear separation of concerns and can be built, packaged and deployed individually, then you've done well!
Otherwise, if you have unrelated code being packaged and deployed together, that's just very bad and it's actually called a big bowl of mud and not a problem with having a single codebase. This can really impede scalability and the stability of your system, as unrelated load profiles will be handled by the same deployment instance.
From here, some of the things that can hurt working in a big codebase are:
Slow deployment pipelines. If all your modules are built and deployed using the same Deployment pipeline, then your deployment might become slow. So a small change might force you to build and run the tests for all modules (as you have a single pipeline) even though you've just changed something small. This can cause context switching and end up being a distraction having to go back and forth to check if things have deployed ok, etc.
Massive projects can make your IDE sluggish and laggy. It is very frustrating and can significantly slow developers down. Yes Intellij, I am talking about you!
One reason I've observed why projects keep growing and becoming super large and harder to maintain even though the time has come to maybe spin off a new service is this. Say we have ServiceA that does A and then we need to do B but B needs A. So the team is under pressure to deliver; deadlines are tight... you get the picture. Someone says, for speed lets add some code to ServiceA to do B as that's the fastest way to get it done. The rest is history!
In my experience, the number one reason why this happens is devs not being armed well enough with the right tools to stand up a new service and do that quickly. By quickly I mean literally, you should be able to create a new service by issuing a single command (or pressing a button) which creates the git repository for you with everything you need in it. That includes:
A deployment pipeline
Any linters you have as standard e.g. code formatters, validators that all your API endpoints parameters are lower-case (if you want to standardize this across your company) and whatever else you think are good practices for developing software.
The main point is that it should be super easy to create a new service by just providing a few configuration parameters Type of project (e.g. Java Vertx, NodeJS), Name etc.
How would you go about doing something like this? It can literally be as simple as using a git template repository or you can have a script that populates some dynamic part of a template project. Some developer portals allow you to create software templates too.
Let me know in the comments, do you have the tools you need to be able to quickly create new projects and deploy them in a straight-forward way?