You’re Not Building Netflix: 9 Architecture Habits Small Teams Should Delete

Small teams love borrowing the aesthetics of big tech.

The problem is that architecture copied from a company with thousands of engineers usually becomes theater inside a team of four.

Complexity feels senior, but most of the time it only hides the product.

Here are nine habits I would delete first:

1. Splitting into microservices before the monolith hurts
2. Adding event-driven flows for simple request-response problems
3. Building abstractions before repeated pain exists
4. Reaching for CQRS where CRUD is enough
5. Choosing Kubernetes before a basic deployment pipeline is stable
6. Adding caches before measuring bottlenecks
7. Introducing multiple databases with no clear need
8. Organizing code by technical layers instead of product areas
9. Writing giant architecture docs nobody updates instead of short ADRs tied to real decisions

The replacement is not “be simple” in the abstract.

The replacement is to earn complexity with evidence.

Start with a modular monolith.
Duplicate a little until the pattern is real.
Use direct calls until coupling becomes a measurable problem.
Deploy the boring way until release pain justifies heavier tooling.
Measure before optimizing.
Keep the default path easy to understand.

A lot of engineering debt comes from solving future problems with present complexity.

Teams feel safe because the system looks “serious,” but they pay for it in slower onboarding, harder debugging, and endless coordination.

You are not building Netflix.

You are building a product with your current team, your current budget, and your current bottlenecks.

Architect for that reality.