Get the latest tech news

Microservices are a tax your startup probably can't afford

Why splitting your codebase too early can quietly destroy your team’s velocity — and what to do instead. In a startup, your survival depends on how quickly you can iterate, ship features, and deliver value to end-users. This is where the foundational architecture of your startup plays a big role; additionally, things like your tech stack and choice of programming language directly affect your team’s velocity. The wrong architecture, especially premature microservices, can substantially hurt productivity and contribute to missed goals in delivering software.

I’ve had this experience when working on greenfield projects for early-stage startups, where questionable decisions were made in terms of software architecture that led to half-finished services and brittle, over-engineered and broken local setups, and demoralized teams who struggle maintaining unnecessary complexity. If you’re building some SaaS product, even a simple SQL database wrapper eventually may bring a lot of internal complexity in the way your business logic works; additionally, you can get to various integrations and background tasks that let transform one set of data to another. When you get to the point that you want to enrich your feature set with Machine Learning functionality or ETL-based jobs, you would just separately build your ML-based infrastructure in Python, due to its rich ecosystem of domain-specific libraries, that naturally any other programming language lacks.

Get the Android app