You are building an MVP. Every decision you make either accelerates or delays your path to revenue. Microservices, despite their popularity, will almost certainly delay it. Here is why?
The Scalability Myth
Microservices is sold on the promise of scalability. But at your early stage, you don't have a scaling problem. You are trying to build an MVP for your product and reach the market asap.
Small Teams Can't Sustain Multiple Services
As you are a new startup your team capacity will be limited in terms of its members and time, embracing microservices will make it hard to the team. Your team will waste time handling infrastructure and dependencies more than building the actual product.
It Burns Money You Don't Have Yet
Pre-seed and Series A investors want to see velocity and validation not architectural sophistication. You will not only waste money but you will waste time as well. Every hour, even every minute is a waste chance to prove your idea into the market.
Fault Isolation Sounds Great Until You Build It
That level of complexity belongs to a later stage, when your product is validated and your team has grown into it.
What to do instead? Modular Monolithic!
Modular Monolithic, it embraces modularity over traditional monolithic application, still your app will be a monolithic but its system components boundaries are well defined. You will have the separations of the microservices but they are contained in a single deployable unit (application), removing the hassle of maintaining a complex infrastructure and its high cost.
Each module owns its own logic and boundaries. For example, Auth handles identity, Billing handles payments, Notifications handles messaging.
None of them bleed into each other, but they all live inside one application.
The Rule of Thumb
Do not architect for the future (what you wish), architect for what you have today (what actually is).
Reach fast to the market, Prove your solution, Enhance it.
Top comments (0)