Monolith first: why I rarely let startups 'plan' for scale

I've been asked to 'design a scalable architecture' on day one of projects with four users. Here's what I tell them: at that scale, your scalability problem is a feature-priority problem wearing a costume.

A modular monolith gives you the structure of a microservice world — enforced boundaries, per-module ownership, clean APIs between modules — with the operational cost of a single deploy. When a module genuinely needs to scale or be owned by a different team, you extract it. The boundary was already there.

The exceptions are real but narrow: teams with 50+ engineers who can't coordinate a monolith deploy, workloads with wildly different scaling curves (real-time streaming next to CRUD), or compliance walls that require separate trust domains. If you don't match those, 'microservices' is a luxury you pay for in on-call misery.

Boring architecture is a feature. The most impressive thing an engineering org can do at 50,000 users is deploy a monolith on a Friday and have nothing happen.