The YC Doctrine: Monolith Until You're Choking
Michael Seibel and Paul Graham repeat the same thesis: build a monolith. Not because it's elegant. Because it's fast.
Your job isn't architecture. It's finding customers who pay. Microservices exist to solve operational problems at scale. If your startup has 2 engineers and 100 daily active users, that's not your problem yet.
Why Engineers Love Microservices (And Why That's Dangerous)
Microservices feel sophisticated. Each service has one job. Deployment is isolated. It's intellectually satisfying.
But here's what actually happens:
Coordination overhead explodes. You now need service discovery, API contracts, versioning across 5 services. A feature touching payments, notifications, and inventory requires changes in three repos. Testing takes weeks instead of days.
Debugging becomes investigative work. A user reports "my order failed." The order service says it worked. The payment service says it rejected. The notification service never ran. Now you're piecing together logs across three systems.
Deployment gets riskier. Blue-green deployments across services? Load balancing? Circuit breakers? You're managing infrastructure complexity your 50-person startup can't sustain.
Meanwhile, your monolith competitor launched 12 features this month. You launched 2, because you spent 3 weeks debugging a service-to-service timeout.
The Hidden Cost: Cognitive Load
Scott Belsky calls this "the mess in the middle"—the overwhelming complexity that kills momentum. In a monolith, you have one codebase. One deployment pipeline. One test suite.
Yes, monoliths get messy. But the mess is comprehensible. A new engineer can read the entire payment flow in an afternoon.
In microservices? A new engineer inherits five codebases, five deployment processes, five monitoring dashboards. They're productive in 3 weeks instead of 3 days.
For a startup burning cash, that's lethal.
When to Actually Move to Microservices
Stripe didn't build microservices in 2010. Shopify didn't in 2006. They moved to services because of specific constraints:
- Database bottleneck. One Postgres instance can't handle your throughput. Sharding requires service boundaries.
- Team growth. Two teams working on the same codebase create merge conflicts and slow deploys. Services decouple them.
- Independent scaling. Your API server needs 50 instances. Your background worker needs 5. Services let you scale each independently.
- Deployment velocity by team. Your payments team ships 5x per day. Your recommendation engine team ships quarterly. Services let them move at their own pace.
Notice something? None of these are problems for 0-to-PMF startups.
The Indian Founder Trap
Indian engineers are (correctly) known for technical depth. But this breeds a specific failure mode: architectural pre-optimization.
You see a problem ("we might have scale issues") and jump to the enterprise solution ("we need event-driven microservices with Kafka").
Meanwhile, 6 months pass. You have no customers. You have perfect infrastructure. You have zero product-market fit.
The right framework: Start monolithic. Add complexity when it bleeds. Belsky calls this "embracing constraint"—constraints force prioritization. A monolith forces you to keep code simple because you can't hide behind service boundaries.
The Decision Framework
Ask yourself:
1. Do you have product-market fit? No? Stop reading about microservices. Build a monolith.
2. Is a specific system bottlenecking you? Database? API latency? Not general scaling concerns—specific ones?
3. Can your team manage distributed systems? Seriously. Not every 5-person startup has someone who understands eventual consistency and network partitions.
4. Is the cost of refactoring lower than the cost of microservices complexity? Usually it's not.
If you answer "no" to #1 and #2, you're not ready.
What to Actually Do
Build a monolith. Python + Django. Node + Express. Go + standard library. Pick something boring that lets you iterate.
Isolate database logic. Use repositories or data access layers. When you do split services, you're not rewriting business logic.
Write for testability. Unit tests run in milliseconds. You can refactor fearlessly. Microservices won't save you from bad design—a monolith with good tests will.
Plan extraction points. If payments becomes its own service someday, what's your migration path? Think about this, but don't build for it.
Get to $10K MRR as a monolith. Then reassess. Stripe's original monolith handled $1B+ in transactions. You're not smarter than them.
The Non-Obvious Insight
Microservices aren't a technical decision. They're an organizational decision masquerading as a technical one. You choose them because your team structure demands it, not because the architecture demands it. If you only have 3 engineers, organizational complexity doesn't exist. So neither does the need for services.
YC backs 500+ startups per batch. The ones that ship products fastest? Monoliths. Every time.