The Microservices Hype Has Caused Real Damage
In the last decade, "microservices" became synonymous with "modern and scalable" in tech circles. Startups that had five engineers and 500 users tried to build like Netflix, which has thousands of engineers and hundreds of millions of users. The result: teams spent more time on infrastructure than on product, deployment complexity killed velocity, and debugging distributed systems became a full-time job. Martin Fowler, who helped popularise microservices, has spent years warning against this pattern for small teams.
What a Monolith Actually Is
A monolith is a single deployable unit that contains all the application's functionality. Shopify, Basecamp, GitHub, and Stack Overflow all ran as monoliths through their most critical growth phases. A well-structured monolith is not messy code — it is modular code that happens to deploy as one unit. It is easier to develop, test, debug, and deploy than a distributed system.
When Microservices Actually Make Sense
Microservices make sense when: different parts of your system have genuinely different scaling requirements (your image processing service needs 10× more compute than your auth service), you have multiple teams that need to deploy independently without coordinating, or you have proven the monolith is a bottleneck (not assumed — proven with data). For Indian startups under 50 engineers and under 1 million daily active users, the answer is almost always: start with a monolith.
The Right Approach for Indian Startups
Build a modular monolith. Organise your code into clearly separated modules (auth, billing, notifications, core business logic) with well-defined interfaces between them. Deploy as one unit. When a specific module needs to scale independently or be owned by a separate team, extract it then — with evidence and engineering bandwidth to support the transition. At DevXAI Technologies we build modular monoliths for all startup clients. Contact hello@devxaitechnologies.com.