It's important to distinguish the how from the what and the why.
Recently there has been substantial discussion around the downsides of service oriented architectures and microservice architectures in particular. While only a few years ago, many people readily adopted microservice architectures due to the numerous benefits they provide such as flexibility in the form of independent deployments, clear ownership, improvements in system stability, and better separation of concerns, in recent years people have begun to decry microservices for their tendency to greatly increase complexity, sometimes making even trivial features difficult to build.
It's important to distinguish the how from the what and the why.
Why splitting your codebase too early can quietly destroy your team’s velocity — and what to do instead. In a startup, your survival depends on how quickly you can iterate, ship features, and deliver value to end-users. This is where the foundational architecture of your startup plays a big role; additionally, things like your tech stack and choice of programming language directly affect your team’s velocity. The wrong architecture, especially premature microservices, can substantially hurt productivity and contribute to missed goals in delivering software.