Microservices solved an organisational problem you might not have
Netflix is the canonical microservices story: hundreds of independently deployable services, each owned by a team that ships on its own schedule. It worked, and it became the template.
The part that travelled poorly is why it worked.
The actual problem being solved
At Netflix's size, the bottleneck was coordination. Hundreds of engineers sharing one deployment pipeline means every release is a negotiation and every rollback affects people who had nothing to do with the change. Splitting into services with clear boundaries let teams stop coordinating.
That is an organisational fix delivered through architecture. It is worth a great deal when coordination is your constraint.
What it costs
You trade function calls for network calls, and network calls fail in ways function calls do not. You need service discovery, distributed tracing, circuit breakers, and a story for what happens when service B is slow and service A is holding connections waiting for it. Netflix built Eureka, Hystrix and Zuul because each of those problems became load-bearing.
A team of six sharing one repository does not have a coordination bottleneck. Adopting the solution to a problem you do not have means paying the full operational cost for none of the benefit, and doing it with fewer people to absorb the complexity.
Uber went partway back
Worth noting that Uber, having gone very far in this direction, published an account of consolidating a sprawl of services into domain-oriented groupings. The stated reasoning was that beyond a certain point the coordination overhead between thousands of tiny services exceeded the isolation benefit they provided.
That is the same tradeoff running in the other direction, and it is a useful correction to the idea that more services is monotonically better.
A reasonable default
Start with one well-structured application. Keep clean internal boundaries so that extracting a piece later is possible. Extract a service when you have a concrete reason — a component with wildly different scaling characteristics, or a team that genuinely needs to deploy independently.
"We might need to scale later" is not that reason. Neither is the fact that a company two hundred times your size does it.