Splitting an app into many services doesn't remove complexity. It moves it from code to the network, a place that's far harder to trace when something goes wrong.
For teams under ten people, the added cost is real: a deployment pipeline per service, cross-service tracing, contract versioning between teams, and a local dev environment that needs six processes alive at once before a single page loads.
The promised benefits — independent scaling and team ownership — only pay off once there are enough teams to own things. With one team, you pay the full cost without getting the benefit.
What we usually recommend: a monolith with firm module boundaries. Split via directories and clear internal interfaces, not via the network. If a module genuinely needs to scale independently later, clean boundaries make separating it a day's work, not a quarter's.