Monolith or microservices for a small team?

Short answer: for a small team, start with a well-structured monolith. Microservices solve organisational and scaling problems you probably do not have yet, and they add real operational cost.

What microservices cost

• Network calls instead of function calls: latency, timeouts, retries, partial failures.
• Distributed data: no simple joins or transactions across services.
• Operational overhead: many deployments, service discovery, monitoring, tracing, versioned contracts.
• Harder local development and testing.

What a monolith gives you

• One deployment, one codebase, simple debugging.
• Transactions and joins that just work.
• Fast refactoring across boundaries.
• A single thing to monitor and back up.

How to keep the option open

Build a modular monolith:

• Organise code into clear modules (billing, catalogue, accounts) with explicit interfaces.
• Do not let modules reach into each other's database tables.
• Communicate through well-defined services or events inside the codebase. Later, if a module truly needs separate scaling or a separate team, it can be extracted.

Signs it may be time to split

1. A part has very different scaling needs.
2. Teams block each other because of a shared deploy cycle.
3. A component needs a different technology or isolation for security.
4. Deploy times or build times become a real bottleneck.

Scaling without microservices

Caching, database indexes, read replicas, queues for background work, horizontally scaling stateless app instances and a CDN carry a long way.

Pitfalls

• Splitting by technical layer rather than by business capability.
• Creating a distributed monolith: services that must deploy together.
• Optimising for traffic you do not have.

Earn complexity when the pain is measurable.