Startups, Do You Really Want to Pay The Microservices Tax?

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. Before diving into specific pitfalls, here’s what you’re actually signing up for when introducing microservices prematurely: Microservices Early On: What You’re Paying For Pain Point Real-World Manifestation Developer Cost Deployment Complexity Orchestrating 5+ services for a single feature Hours lost per release Local Dev Fragility Docker sprawl, broken scripts, platform-specific hacks Slow onboarding, frequent breakage CI/CD Duplication Multiple pipelines with duplicated logic Extra toil per service Cross-Service Coupling "Decoupled" services tightly linked by shared state Slower changes, coordination tax Observability Overhead Distributed tracing, logging, monitoring Weeks to instrument properly Test Suite Fragmentation Tests scattered across services Brittle tests, low confidence Let's unpack why microservices often backfire early on, where they genuinely help, and how to structure your startup's systems for speed and survival. Monoliths Are Not the Enemy 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. With time, sometimes unnecessary features, it's inevitable that your app may grow messy. The great thing about monoliths is: they still work. Monoliths, even when messy, keep your team focused on what matters most: Staying alive Delivering customer value The biggest advantage of monoliths is their simplicity in deployment. Generally, such projects are built around existing frameworks — it could be Django for Python, ASP.Net for C#, Nest.js for Node.js apps, etc. When sticking to monolithic architecture, you get the biggest advantage over fancy microservices — a wide support of the open source community and project maintainers who primarily designed those frameworks to work as a single process, monolithic app. At one real-estate startup where I led the front-end team, and occasionally consulted the backend team on technology choices, we had an interesting evolution of a Laravel-based app. What started as a small dashboard for real-estate agents to manage deals gradually grew into a much larger system. Over time, it evolved into a feature-rich suite that handled hundreds of gigabytes of documents and integrated with dozens of third-party services. Yet, it remained built on a fairly basic PHP stack running on Apache. The team leaned heavily on best practices recommended by the Laravel community. That discipline paid off, we were able to scale the application’s capabilities significantly while still meeting the business’s needs and expectations. Interestingly, we never needed to decouple the system into microservices or adopt more complex infrastructure patterns. We avoided a lot of accidental complexity that way. The simplicity of the architecture gave us leverage. This echoes what others have written — like Basecamp’s take on the “Majestic Monolith”, which lays out why simplicity is a superpower early on. People often point out that it's hard to make monoliths scalable, but it's bad modularization inside the monolith that may bring such problems. Takeaway: A well-structured monolith keeps your team focused on shipping, not firefighting. But Isn’t Microservices “Best Practice”? A lot of engineers reach for microservices early, thinking they’re “the right way.” And sure — at scale, they can help. But in a startup, that same complexity turns into drag. Microservices only pay off when you have real scaling bottlenecks, large teams, or independently evolving domains. Before that? You’re paying the price without getting the benefit: duplicated infra, fragile local setups, and slow iteration. For example, Segment eventually reversed their microservice split for this exact reason — too much cost, not enough value. Takeaway: Microservices are a scaling tool — not a starting template. Where Microservices Go Wrong (Especially Early On) In one early-stage team I advised, the decision to split services created more PM-engineering coordination overhead than technical gain. Architecture shaped not just code, but how we planned, estimated, and shipped. That organizational tax is easy to miss — until it’s too late. Here are the most common anti-patterns that creep in early. 1. Arbitrary Service Boundaries In theory, you often see suggestions on splitting your applications by business logic domain — users service, products service, orders service, and so on. This often borrows from Domain-Driven Design or Clean Architecture concepts — which make sense at scale, but in early-stage products, they can ossify structure prematurely, before the product itself is stable or validated. You end up with: Shared databases Cross-service calls for simple workflows Coupling disguised as "separation" At one project, I watched a team separating user, authentication, and authorization into separate services, which led to deployment complexity and difficulties in service coordination for any API operation they were building. In reality, business logic doesn't directly map to service boundaries. Premature separation can make the system more fragile and often times difficult to introduce changes quickly. Instead, isolate bottlenecks surgically — based on real scaling pain, not theoretical elegance. When I’ve coached early-stage teams, we’ve sometimes used internal flags or deployment toggles to simulate future service splits — without the immediate operational burden. This gave product and engineering room to explore boundaries organically, before locking in premature infrastructure. Takeaway: Don’t split by theory — split by actual bottlenecks. 2. Repository and Infrastructure Sprawl When working on the application, typically a next set of things is important: Code style consistency (linting) Testing infrastructure, including integration testing Local environment configuration Documentation CI/CD configuration When dealing with microservices, you need to multiply those requirements by the number of services. If your project is structured as a monorepo, you can simplify your life by having a central CI/CD configuration (when working with GitHub Actions or GitLab CI). Some teams separate microservices into separate repositories, which makes it way harder to maintain the code consistency and the same set of configurations without extra effort or tools. For a three-person team, this is brutal. Context switching across repositories and tooling adds up to the development time of every feature that is shipped. Mitigating issues by using monorepos and a single programming language There are various ways to mitigate this problem. For early projects, the single most important thing is — keeping your code in a monorepo. This ensures that there's a single version of code that exists on prod, and it's much easier to coordinate code reviews and collaborate for smaller teams. For Node.js projects, I strongly recommend using a monorepo tool like nx or turborepo. Both: Simplify CI/CD config across subprojects Support dependency graph-based build caching Let you treat internal services as TypeScript libraries (via ES6 imports) These tools save time otherwise spent writing glue code or reinventing orchestration. That said, they come with real tradeoffs: Complex dependency trees can grow fast CI performance tuning is non-trivial You may need faster tooling (like bun) to keep build times down To summarize: Tooling like nx or turborepo gives small teams monorepo velocity — if you’re willing to invest in keeping them clean. When developing go-based microservices, a good idea early in the development is to use a single go workspace with the replace directive in go.mod. Eventually, as the software scales, it's possible to effortlessly separate go modules into separate repositories. Takeaway: A monorepo with shared infra buys you time, consistency, and sanity. 3. Broken Local Dev = Broken Velocity If it takes three hours, a custom shell script, and a Docker marathon just to run your app locally, you've already lost velocity. Early projects often suffer from: Missing documentation Obsolete dependencies OS-specific hacks (hello, Linux-only setups) In my experience, when I received projects from past development teams, they were often developed for a single operating system. Some devs preferred building on macOS and never bothered supporting their shell scripts on Windows. In my past teams, I had engineers working on Windows machines, and often it required rewriting shell scripts or fully understanding and reverse engineering the process of getting the local environment running. With time, we standardized environment setup across dev OSes to reduce onboarding friction — a small investment that saved hours per new engineer. It was frustrating — but it taught a lasting lesson on how important it is to get the code running on any laptop your new developer may be using. At another project, a solo dev had created a fragile microservice setup, that the workflow of running Docker containers mounted to a local file system. Of course, you pay a little price for running processes as containers when your computer runs Linux. But onboarding a new front-end dev with an older Windows laptop turned into a nightmare. They had to spin up ten containers just to view the UI. Everything broke — volumes, networking, container compatibility — and the setup very poorly documented. This created a major friction point during onboarding. We ended up hacking together a Node.js proxy that mimicked the nginx/Docker configuration without containers. It wasn’t elegant, but it let the dev get unblocked and start contributing. Takeaway: If your app only runs on one OS, your team’s productivity is one laptop away from disaster. Tip: Ideally, aim for git clone && make up to have the project running locally. If it's not possible, then maintaining an up-to-date README file with instructions for Windows/macOS/Linux is a must. Nowadays, there are some programming languages and toolchains that don't work well on Windows (like OCaml), but the modern widely popular stack runs just fine on every widely used operating system; by limiting your local setup to a single operating system, it's often a symptom of under-investment in DX. 4. Technology Mismatch Beyond architecture, your tech stack also shapes how painful microservices become — not every language shines in a microservice architecture. Node.js and Python: Great for rapid iteration, but managing build artifacts, dependency versions, and runtime consistency across services gets painful fast. Go: Compiles to static binaries, fast build times, and low operational overhead. More natural fit when splitting is truly needed. It's very important to pick the right technical stack early on. If you look for performance, maybe look for the JVM and its ecosystem and ability to deploy artifacts at scale and run them in microservice-based architectures. If you do very fast iterations and prototype quickly without worrying about scaling your deployment infrastructure — you're good with something like Python. It's quite often for teams to realise that there are big issues with their choice of technology that wasn't apparent initially, and they had to pay the price of rebuilding the back-end in a different programming language (like those guys were forced to do something about legacy Python 2 codebase and migrated to Go). But on the contrary, if you really need to, you can bridge multiple programming languages with protocols like gRPC or async message communication. And it's often the way to go about things. 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. But such decisions should be made when there's enough head count to justify this venture; otherwise, the small team will be eternally drawn into the endless complexity of bridging multiple software stacks together. Takeaway: Match the tech to your constraints, not your ambition. 5. Hidden Complexity: Communication and Monitoring Microservices introduce an invisible web of needs: Service discovery API versioning Retries, circuit breakers, fallbacks Distributed tracing Centralized logging and alerting In a monolith, a bug might be a simple stack trace. In a distributed system, it's "why does service A fail when B’s deployment lags C by 30 seconds?" You would have to thoroughly invest in your observability stack. To do it "properly", it requires instrumenting your applications in specific ways, e.g. integrating OpenTelemetry to support tracing, or relying on your cloud provider's tools like AWS XRay if you go with a complex serverless system. But at this point, you have to completely shift your focus from application code towards building complex monitoring infrastructure that to validate whether your architecture is actually functioning in production. Of course, some of the observability instrumentation is needed to be performed on monolith apps, but it's way simpler than doing that in terms of the number of services in a consistent way. Tip: Understand that distributed systems aren't free. They're a commitment to a whole new class of engineering challenges. When Microservices Do Make Sense Despite the mentioned difficulties with microservices, there are times where service-level decoupling actually is very beneficial. There are cases where it definitely helps: Workload Isolation: a common example for that would be in AWS best practices on using S3 event notifications — when an image gets loaded to S3, trigger an image resizing/OCR process, etc. Why it is useful: we can decouple obscure data processing libraries in a self-isolated service and make it API focused solely on image processing and generating output from the uploaded data. Your upstream clients that upload data to S3 aren't coupled with this service, and there's less overhead in instrumenting such a service because of its relative simplicity. Divergent Scalability Needs: — Imagine you are building an AI product. One part of the system (web API) that triggers ML workloads and shows past results isn't resource intensive, it's lightweight, because it interacts mostly with the database. On the contrary, ML model runs on GPUs is actually heavy to run and requires special machines with GPU support with additional configuration. By splitting these parts of the application into separate services running on different machines, you can scale them independently. Different Runtime Requirements: — Let’s say you've got some legacy part of code written in C++. You have 2 choices — magically convert it to your core programming language or find ways to integrate it with a codebase. Depending on the complexity of that legacy app, you would have to write glue code, implementing additional networking/protocols to establish interactions with that service, but the bottom line is — you will likely have to separate this app as a separate service due to runtime incompatibilities. I would say even more, you could write your main app in C++ as well, but because of different compiler configurations and library dependencies, you wouldn't be able to easily compile things together as a single binary. Large-scale engineering orgs have wrestled with similar challenges. For instance, Uber's engineering team documented their shift to a domain-oriented microservice architecture — not out of theoretical purity, but in response to real complexity across teams and scaling boundaries. Their post is a good example of how microservices can work when you have the organizational maturity and operational overhead to support them. At one project, that also happens to be a real-estate one, we had code from a previous team that runs Python-based analytics workloads that loads data into MS-SQL db, we found that it would be a waste to build on top of it a Django app. The code had different runtime dependencies and was pretty self-isolated, so we kept it separate and only revisited it when something wasn't working as expected. This worked for us even for a small team, because this analytics generation service was a part that required rare changes or maintenance. Takeaway: Use microservices when workloads diverge — not just because they sound clean. Practical Guidance for Startups If you're shipping your first product, here's the playbook I'd recommend: Start monolithic. Pick a common framework and focus on getting the features done. All known frameworks are more than good enough to build some API or website and serve the users. Don't follow the hype, stick to the boring way of doing things; you can thank yourself later. Single repo. Don't bother splitting your code into multiple repositories. I’ve worked with founders who wanted to separate repos to reduce the risk of contractors copying IP — a valid concern. But in practice, it added more friction than security: slower builds, fragmented CI/CD, and poor visibility across teams. The marginal IP protection wasn’t worth the operational drag, especially when proper access controls inside a monorepo were easier to manage. For early-stage teams, clarity and speed tend to matter more than theoretical security gains. Dead-simple local setup. Make make up work. If it takes more, be very specific on the steps, record a video/Loom, and add screenshots. If your code is going to be run by an intern or junior dev, they'll likely hit a roadblock, and you’ll spend time explaining how to troubleshoot an issue. I found that documenting every possible issue for every operating system eliminates time spent clarifying why certain things in a local setup didn't work. Invest early in CI/CD. Even if it's a simple HTML that you could just scp to a server manually, you could automate this and rely on source control with CI/CD to do it. When the setup is properly automated, you just forget about your continuous integration infrastructure and focus on features. I've seen many teams and founders when working with outsourced teams often be cheap on CI/CD, and that results in the team being demoralized and annoyed by manual deployment processes. Split surgically. Only split when it clearly solves a painful bottleneck. Otherwise, invest in modularity and tests inside the monolith — it’s faster and easier to maintain. And above all: optimize for developer velocity. Velocity is your startup’s oxygen. Premature microservices leak that oxygen slowly — until one day, you can't breathe. Takeaway: Start simple, stay pragmatic, and split only when you must. If you go with a microservice-based approach I had micro-service-based projects created earlier than they should have been done, and here are the next recommendations that I could give on that: Evaluate your technical stack that powers your micro-service-based architecture. Invest in developer experience tooling. When you have service-based separation, you now need to think about automating your microservice stack, automating config across both local and production environments. In certain projects, I had to build a separate CLI that does administrative tasks on the monorepository. One project I had contained 15-20 microservice deployments, and for the local environment, I had to create a cli-tool for generating docker-compose.yml files dynamically to achieve seamless one-command start-up for the regular developer. Focus on reliable communication protocols around service communication. If it's async messaging, make sure your message schemas are consistent and standardized. If it's REST, focus on OpenAPI documentation. Inter-service communication clients must implement many things that don't come out-of-the-box: retries with exponential backoff, timeouts. A typical bare-bones gRPC client requires you to manually factor those additional things to make sure you don't suffer from transient errors. Ensure that your unit, integration testing, and end-to-end testing setup is stable and scales with the amount of service-level separations you introduce into your codebase. On smaller projects that use micro-service-based workloads, you would likely default to a shared library with common helpers for instrumenting your observability, communication code in a consistent way. An important consideration here — keep your shared library as small as possible. Any major change forces a rebuild across all dependent services — even if unrelated. Look into observability earlier on. Add structured-JSON logs and create various correlation IDs for debugging things once your app is deployed. Even basic helpers that output rich logging information (until you instrumented your app with proper logging/tracing facilities) often save time figuring out flaky user flows. To summarize: if you're still going for microservices, you should beforehand understand the tax you're going to pay in terms of additional development time and maintenance to make the setup workable for every engineer in your team. Takeaway: If you embrace complexity, invest fully in making it manageable. Conclusion Premature microservices are a tax you can’t afford. Stay simple. Stay alive. Split only when the pain makes it obvious. Survive first. Scale later. Choose the simplest system that works — and earn every layer of complexity you add. Related resources Monolith First — Martin Fowler The Majestic Monolith — DHH / Basecamp Goodbye Microservices: From 100s of problem children to 1 superstar — Segment Eng. Deconstructing the Monolith — Shopify Eng. Domain‑Oriented Microservice Architecture — Uber Eng. Go + Services = One Goliath Project — Khan Academy Why splitting your codebase too early can quietly destroy your team’s velocity — and what to do instead. Why splitting your codebase too early can quietly destroy your team’s velocity — and what to do instead . 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. your survival depends on how quickly you can iterate, ship features, and deliver value to end-users 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. brittle, over-engineered and broken local setups demoralized teams Before diving into specific pitfalls, here’s what you’re actually signing up for when introducing microservices prematurely: Microservices Early On: What You’re Paying For Microservices Early On: What You’re Paying For Pain Point Real-World Manifestation Developer Cost Deployment Complexity Orchestrating 5+ services for a single feature Hours lost per release Local Dev Fragility Docker sprawl, broken scripts, platform-specific hacks Slow onboarding, frequent breakage CI/CD Duplication Multiple pipelines with duplicated logic Extra toil per service Cross-Service Coupling "Decoupled" services tightly linked by shared state Slower changes, coordination tax Observability Overhead Distributed tracing, logging, monitoring Weeks to instrument properly Test Suite Fragmentation Tests scattered across services Brittle tests, low confidence Pain Point Real-World Manifestation Developer Cost Deployment Complexity Orchestrating 5+ services for a single feature Hours lost per release Local Dev Fragility Docker sprawl, broken scripts, platform-specific hacks Slow onboarding, frequent breakage CI/CD Duplication Multiple pipelines with duplicated logic Extra toil per service Cross-Service Coupling "Decoupled" services tightly linked by shared state Slower changes, coordination tax Observability Overhead Distributed tracing, logging, monitoring Weeks to instrument properly Test Suite Fragmentation Tests scattered across services Brittle tests, low confidence Pain Point Real-World Manifestation Developer Cost Pain Point Pain Point Real-World Manifestation Real-World Manifestation Developer Cost Developer Cost Deployment Complexity Orchestrating 5+ services for a single feature Hours lost per release Deployment Complexity Deployment Complexity Orchestrating 5+ services for a single feature Orchestrating 5+ services for a single feature Hours lost per release Hours lost per release Hours lost per release Local Dev Fragility Docker sprawl, broken scripts, platform-specific hacks Slow onboarding, frequent breakage Local Dev Fragility Local Dev Fragility Docker sprawl, broken scripts, platform-specific hacks Docker sprawl, broken scripts, platform-specific hacks Slow onboarding, frequent breakage Slow onboarding, frequent breakage Slow onboarding, frequent breakage CI/CD Duplication Multiple pipelines with duplicated logic Extra toil per service CI/CD Duplication CI/CD Duplication Multiple pipelines with duplicated logic Multiple pipelines with duplicated logic Extra toil per service Extra toil per service Extra toil per service Cross-Service Coupling "Decoupled" services tightly linked by shared state Slower changes, coordination tax Cross-Service Coupling Cross-Service Coupling "Decoupled" services tightly linked by shared state "Decoupled" services tightly linked by shared state Slower changes, coordination tax Slower changes, coordination tax Slower changes, coordination tax Observability Overhead Distributed tracing, logging, monitoring Weeks to instrument properly Observability Overhead Observability Overhead Distributed tracing, logging, monitoring Distributed tracing, logging, monitoring Weeks to instrument properly Weeks to instrument properly Weeks to instrument properly Test Suite Fragmentation Tests scattered across services Brittle tests, low confidence Test Suite Fragmentation Test Suite Fragmentation Tests scattered across services Tests scattered across services Brittle tests, low confidence Brittle tests, low confidence Brittle tests, low confidence Let's unpack why microservices often backfire early on, where they genuinely help, and how to structure your startup's systems for speed and survival. Monoliths Are Not the Enemy 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. With time, sometimes unnecessary features, it's inevitable that your app may grow messy. The great thing about monoliths is: they still work. Monoliths, even when messy, keep your team focused on what matters most : Monoliths, even when messy, keep your team focused on what matters most Staying alive Delivering customer value Staying alive Staying alive Delivering customer value Delivering customer value The biggest advantage of monoliths is their simplicity in deployment. Generally, such projects are built around existing frameworks — it could be Django for Python, ASP.Net for C#, Nest.js for Node.js apps, etc. When sticking to monolithic architecture, you get the biggest advantage over fancy microservices — a wide support of the open source community and project maintainers who primarily designed those frameworks to work as a single process, monolithic app. ASP.Net At one real-estate startup where I led the front-end team, and occasionally consulted the backend team on technology choices, we had an interesting evolution of a Laravel-based app. What started as a small dashboard for real-estate agents to manage deals gradually grew into a much larger system. Over time, it evolved into a feature-rich suite that handled hundreds of gigabytes of documents and integrated with dozens of third-party services. Yet, it remained built on a fairly basic PHP stack running on Apache. The team leaned heavily on best practices recommended by the Laravel community. That discipline paid off, we were able to scale the application’s capabilities significantly while still meeting the business’s needs and expectations. Interestingly, we never needed to decouple the system into microservices or adopt more complex infrastructure patterns. We avoided a lot of accidental complexity that way. The simplicity of the architecture gave us leverage. This echoes what others have written — like Basecamp’s take on the “Majestic Monolith” , which lays out why simplicity is a superpower early on. “Majestic Monolith” People often point out that it's hard to make monoliths scalable, but it's bad modularization inside the monolith that may bring such problems. inside Takeaway: A well-structured monolith keeps your team focused on shipping, not firefighting. Takeaway: A well-structured monolith keeps your team focused on shipping, not firefighting. But Isn’t Microservices “Best Practice”? A lot of engineers reach for microservices early, thinking they’re “the right way.” And sure — at scale, they can help. But in a startup, that same complexity turns into drag. Microservices only pay off when you have real scaling bottlenecks, large teams, or independently evolving domains. Before that? You’re paying the price without getting the benefit: duplicated infra, fragile local setups, and slow iteration. For example, Segment eventually reversed their microservice split for this exact reason — too much cost, not enough value. Segment reversed their microservice split Takeaway: Microservices are a scaling tool — not a starting template. Takeaway: Microservices are a scaling tool — not a starting template. Where Microservices Go Wrong (Especially Early On) In one early-stage team I advised, the decision to split services created more PM-engineering coordination overhead than technical gain. Architecture shaped not just code, but how we planned, estimated, and shipped. That organizational tax is easy to miss — until it’s too late. Here are the most common anti-patterns that creep in early. 1. Arbitrary Service Boundaries In theory, you often see suggestions on splitting your applications by business logic domain — users service, products service, orders service, and so on. This often borrows from Domain-Driven Design or Clean Architecture concepts — which make sense at scale, but in early-stage products, they can ossify structure prematurely, before the product itself is stable or validated. You end up with: Shared databases Cross-service calls for simple workflows Coupling disguised as "separation" Shared databases Cross-service calls for simple workflows Coupling disguised as "separation" At one project, I watched a team separating user, authentication, and authorization into separate services, which led to deployment complexity and difficulties in service coordination for any API operation they were building. In reality, business logic doesn't directly map to service boundaries. Premature separation can make the system more fragile and often times difficult to introduce changes quickly. Instead, isolate bottlenecks surgically — based on real scaling pain, not theoretical elegance. When I’ve coached early-stage teams, we’ve sometimes used internal flags or deployment toggles to simulate future service splits — without the immediate operational burden. This gave product and engineering room to explore boundaries organically, before locking in premature infrastructure. Takeaway: Don’t split by theory — split by actual bottlenecks. Takeaway: Don’t split by theory — split by actual bottlenecks. 2. Repository and Infrastructure Sprawl When working on the application, typically a next set of things is important: Code style consistency (linting) Testing infrastructure, including integration testing Local environment configuration Documentation CI/CD configuration Code style consistency (linting) Testing infrastructure, including integration testing Local environment configuration Documentation CI/CD configuration When dealing with microservices, you need to multiply those requirements by the number of services. If your project is structured as a monorepo, you can simplify your life by having a central CI/CD configuration (when working with GitHub Actions or GitLab CI). Some teams separate microservices into separate repositories, which makes it way harder to maintain the code consistency and the same set of configurations without extra effort or tools. For a three-person team, this is brutal. Context switching across repositories and tooling adds up to the development time of every feature that is shipped. Mitigating issues by using monorepos and a single programming language There are various ways to mitigate this problem. For early projects, the single most important thing is — keeping your code in a monorepo. This ensures that there's a single version of code that exists on prod, and it's much easier to coordinate code reviews and collaborate for smaller teams. For Node.js projects, I strongly recommend using a monorepo tool like nx or turborepo . Both: nx turborepo Simplify CI/CD config across subprojects Support dependency graph-based build caching Let you treat internal services as TypeScript libraries (via ES6 imports) Simplify CI/CD config across subprojects Support dependency graph-based build caching Let you treat internal services as TypeScript libraries (via ES6 imports) These tools save time otherwise spent writing glue code or reinventing orchestration. That said, they come with real tradeoffs: Complex dependency trees can grow fast CI performance tuning is non-trivial You may need faster tooling (like bun) to keep build times down Complex dependency trees can grow fast CI performance tuning is non-trivial You may need faster tooling (like bun) to keep build times down To summarize: Tooling like nx or turborepo gives small teams monorepo velocity — if you’re willing to invest in keeping them clean. nx turborepo When developing go -based microservices, a good idea early in the development is to use a single go workspace with the replace directive in go.mod . Eventually, as the software scales, it's possible to effortlessly separate go modules into separate repositories. go go replace go.mod go Takeaway: A monorepo with shared infra buys you time, consistency, and sanity. Takeaway: A monorepo with shared infra buys you time, consistency, and sanity. 3. Broken Local Dev = Broken Velocity If it takes three hours, a custom shell script, and a Docker marathon just to run your app locally, you've already lost velocity. If it takes three hours, a custom shell script, and a Docker marathon just to run your app locally, you've already lost velocity. Early projects often suffer from: Missing documentation Obsolete dependencies OS-specific hacks (hello, Linux-only setups) Missing documentation Obsolete dependencies OS-specific hacks (hello, Linux-only setups) In my experience, when I received projects from past development teams, they were often developed for a single operating system. Some devs preferred building on macOS and never bothered supporting their shell scripts on Windows. In my past teams, I had engineers working on Windows machines, and often it required rewriting shell scripts or fully understanding and reverse engineering the process of getting the local environment running. With time, we standardized environment setup across dev OSes to reduce onboarding friction — a small investment that saved hours per new engineer. It was frustrating — but it taught a lasting lesson on how important it is to get the code running on any laptop your new developer may be using. At another project, a solo dev had created a fragile microservice setup, that the workflow of running Docker containers mounted to a local file system. Of course, you pay a little price for running processes as containers when your computer runs Linux. But onboarding a new front-end dev with an older Windows laptop turned into a nightmare. They had to spin up ten containers just to view the UI. Everything broke — volumes, networking, container compatibility — and the setup very poorly documented. This created a major friction point during onboarding. We ended up hacking together a Node.js proxy that mimicked the nginx/Docker configuration without containers. It wasn’t elegant, but it let the dev get unblocked and start contributing. Takeaway: If your app only runs on one OS, your team’s productivity is one laptop away from disaster. Takeaway: If your app only runs on one OS, your team’s productivity is one laptop away from disaster. Tip: Ideally, aim for git clone && make up to have the project running locally. If it's not possible, then maintaining an up-to-date README file with instructions for Windows/macOS/Linux is a must. Nowadays, there are some programming languages and toolchains that don't work well on Windows (like OCaml), but the modern widely popular stack runs just fine on every widely used operating system; by limiting your local setup to a single operating system, it's often a symptom of under-investment in DX. Tip: git clone && make up 4. Technology Mismatch Beyond architecture, your tech stack also shapes how painful microservices become — not every language shines in a microservice architecture. Node.js and Python: Great for rapid iteration, but managing build artifacts, dependency versions, and runtime consistency across services gets painful fast. Go: Compiles to static binaries, fast build times, and low operational overhead. More natural fit when splitting is truly needed. Node.js and Python: Great for rapid iteration, but managing build artifacts, dependency versions, and runtime consistency across services gets painful fast. Node.js and Python: Go: Compiles to static binaries, fast build times, and low operational overhead. More natural fit when splitting is truly needed. Go: It's very important to pick the right technical stack early on. If you look for performance, maybe look for the JVM and its ecosystem and ability to deploy artifacts at scale and run them in microservice-based architectures. If you do very fast iterations and prototype quickly without worrying about scaling your deployment infrastructure — you're good with something like Python. It's quite often for teams to realise that there are big issues with their choice of technology that wasn't apparent initially, and they had to pay the price of rebuilding the back-end in a different programming language (like those guys were forced to do something about legacy Python 2 codebase and migrated to Go). those guys But on the contrary, if you really need to, you can bridge multiple programming languages with protocols like gRPC or async message communication. And it's often the way to go about things. 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. But such decisions should be made when there's enough head count to justify this venture; otherwise, the small team will be eternally drawn into the endless complexity of bridging multiple software stacks together. gRPC Takeaway: Match the tech to your constraints, not your ambition. Takeaway: Match the tech to your constraints, not your ambition. 5. Hidden Complexity: Communication and Monitoring Microservices introduce an invisible web of needs: Service discovery API versioning Retries, circuit breakers, fallbacks Distributed tracing Centralized logging and alerting Service discovery API versioning Retries, circuit breakers, fallbacks Distributed tracing Centralized logging and alerting In a monolith, a bug might be a simple stack trace. In a distributed system, it's "why does service A fail when B’s deployment lags C by 30 seconds?" You would have to thoroughly invest in your observability stack. To do it "properly", it requires instrumenting your applications in specific ways, e.g. integrating OpenTelemetry to support tracing, or relying on your cloud provider's tools like AWS XRay if you go with a complex serverless system. But at this point, you have to completely shift your focus from application code towards building complex monitoring infrastructure that to validate whether your architecture is actually functioning in production. actually Of course, some of the observability instrumentation is needed to be performed on monolith apps, but it's way simpler than doing that in terms of the number of services in a consistent way. Tip: Understand that distributed systems aren't free. They're a commitment to a whole new class of engineering challenges. Tip: distributed systems aren't free. aren't free. When Microservices Do Make Sense Do Despite the mentioned difficulties with microservices, there are times where service-level decoupling actually is very beneficial. There are cases where it definitely helps: Workload Isolation: a common example for that would be in AWS best practices on using S3 event notifications — when an image gets loaded to S3, trigger an image resizing/OCR process, etc. Why it is useful: we can decouple obscure data processing libraries in a self-isolated service and make it API focused solely on image processing and generating output from the uploaded data. Your upstream clients that upload data to S3 aren't coupled with this service, and there's less overhead in instrumenting such a service because of its relative simplicity. Divergent Scalability Needs: — Imagine you are building an AI product. One part of the system (web API) that triggers ML workloads and shows past results isn't resource intensive, it's lightweight, because it interacts mostly with the database. On the contrary, ML model runs on GPUs is actually heavy to run and requires special machines with GPU support with additional configuration. By splitting these parts of the application into separate services running on different machines, you can scale them independently. Different Runtime Requirements: — Let’s say you've got some legacy part of code written in C++. You have 2 choices — magically convert it to your core programming language or find ways to integrate it with a codebase. Depending on the complexity of that legacy app, you would have to write glue code, implementing additional networking/protocols to establish interactions with that service, but the bottom line is — you will likely have to separate this app as a separate service due to runtime incompatibilities. I would say even more, you could write your main app in C++ as well, but because of different compiler configurations and library dependencies, you wouldn't be able to easily compile things together as a single binary. Workload Isolation : a common example for that would be in AWS best practices on using S3 event notifications — when an image gets loaded to S3, trigger an image resizing/OCR process, etc. Why it is useful: we can decouple obscure data processing libraries in a self-isolated service and make it API focused solely on image processing and generating output from the uploaded data. Your upstream clients that upload data to S3 aren't coupled with this service, and there's less overhead in instrumenting such a service because of its relative simplicity. Workload Isolation Divergent Scalability Needs: — Imagine you are building an AI product. One part of the system ( web API ) that triggers ML workloads and shows past results isn't resource intensive, it's lightweight, because it interacts mostly with the database. On the contrary, ML model runs on GPUs is actually heavy to run and requires special machines with GPU support with additional configuration. By splitting these parts of the application into separate services running on different machines, you can scale them independently. Divergent Scalability Needs: web API Different Runtime Requirements: — Let’s say you've got some legacy part of code written in C++. You have 2 choices — magically convert it to your core programming language or find ways to integrate it with a codebase. Depending on the complexity of that legacy app, you would have to write glue code, implementing additional networking/protocols to establish interactions with that service, but the bottom line is — you will likely have to separate this app as a separate service due to runtime incompatibilities. I would say even more, you could write your main app in C++ as well, but because of different compiler configurations and library dependencies, you wouldn't be able to easily compile things together as a single binary. Different Runtime Requirements: Large-scale engineering orgs have wrestled with similar challenges. For instance, Uber's engineering team documented their shift to a domain-oriented microservice architecture — not out of theoretical purity, but in response to real complexity across teams and scaling boundaries. Their post is a good example of how microservices can work when you have the organizational maturity and operational overhead to support them. documented their shift to a domain-oriented microservice architecture At one project, that also happens to be a real-estate one, we had code from a previous team that runs Python-based analytics workloads that loads data into MS-SQL db, we found that it would be a waste to build on top of it a Django app. The code had different runtime dependencies and was pretty self-isolated, so we kept it separate and only revisited it when something wasn't working as expected. This worked for us even for a small team, because this analytics generation service was a part that required rare changes or maintenance. Takeaway: Use microservices when workloads diverge — not just because they sound clean. Takeaway: Use microservices when workloads diverge — not just because they sound clean. Practical Guidance for Startups If you're shipping your first product, here's the playbook I'd recommend: Start monolithic. Pick a common framework and focus on getting the features done. All known frameworks are more than good enough to build some API or website and serve the users. Don't follow the hype, stick to the boring way of doing things; you can thank yourself later. Single repo. Don't bother splitting your code into multiple repositories. I’ve worked with founders who wanted to separate repos to reduce the risk of contractors copying IP — a valid concern. But in practice, it added more friction than security: slower builds, fragmented CI/CD, and poor visibility across teams. The marginal IP protection wasn’t worth the operational drag, especially when proper access controls inside a monorepo were easier to manage. For early-stage teams, clarity and speed tend to matter more than theoretical security gains. Dead-simple local setup. Make make up work. If it takes more, be very specific on the steps, record a video/Loom, and add screenshots. If your code is going to be run by an intern or junior dev, they'll likely hit a roadblock, and you’ll spend time explaining how to troubleshoot an issue. I found that documenting every possible issue for every operating system eliminates time spent clarifying why certain things in a local setup didn't work. Invest early in CI/CD. Even if it's a simple HTML that you could just scp to a server manually, you could automate this and rely on source control with CI/CD to do it. When the setup is properly automated, you just forget about your continuous integration infrastructure and focus on features. I've seen many teams and founders when working with outsourced teams often be cheap on CI/CD, and that results in the team being demoralized and annoyed by manual deployment processes. Split surgically. Only split when it clearly solves a painful bottleneck. Otherwise, invest in modularity and tests inside the monolith — it’s faster and easier to maintain. Start monolithic. Pick a common framework and focus on getting the features done. All known frameworks are more than good enough to build some API or website and serve the users. Don't follow the hype, stick to the boring way of doing things; you can thank yourself later. Start monolithic. Single repo. Don't bother splitting your code into multiple repositories. I’ve worked with founders who wanted to separate repos to reduce the risk of contractors copying IP — a valid concern. But in practice, it added more friction than security: slower builds, fragmented CI/CD, and poor visibility across teams. The marginal IP protection wasn’t worth the operational drag, especially when proper access controls inside a monorepo were easier to manage. For early-stage teams, clarity and speed tend to matter more than theoretical security gains. Single repo. Dead-simple local setup. Make make up work. If it takes more, be very specific on the steps, record a video/Loom, and add screenshots. If your code is going to be run by an intern or junior dev, they'll likely hit a roadblock, and you’ll spend time explaining how to troubleshoot an issue. I found that documenting every possible issue for every operating system eliminates time spent clarifying why certain things in a local setup didn't work. Dead-simple local setup. make up Invest early in CI/CD. Even if it's a simple HTML that you could just scp to a server manually, you could automate this and rely on source control with CI/CD to do it. When the setup is properly automated, you just forget about your continuous integration infrastructure and focus on features. I've seen many teams and founders when working with outsourced teams often be cheap on CI/CD, and that results in the team being demoralized and annoyed by manual deployment processes. Invest early in CI/CD. scp Split surgically. Only split when it clearly solves a painful bottleneck. Otherwise, invest in modularity and tests inside the monolith — it’s faster and easier to maintain. Split surgically. And above all: optimize for developer velocity. optimize for developer velocity. Velocity is your startup’s oxygen. Premature microservices leak that oxygen slowly — until one day, you can't breathe. Velocity is your startup’s oxygen. Takeaway: Start simple, stay pragmatic, and split only when you must. Takeaway: Start simple, stay pragmatic, and split only when you must. If you go with a microservice-based approach I had micro-service-based projects created earlier than they should have been done, and here are the next recommendations that I could give on that: Evaluate your technical stack that powers your micro-service-based architecture. Invest in developer experience tooling. When you have service-based separation, you now need to think about automating your microservice stack, automating config across both local and production environments. In certain projects, I had to build a separate CLI that does administrative tasks on the monorepository. One project I had contained 15-20 microservice deployments, and for the local environment, I had to create a cli-tool for generating docker-compose.yml files dynamically to achieve seamless one-command start-up for the regular developer. Focus on reliable communication protocols around service communication. If it's async messaging, make sure your message schemas are consistent and standardized. If it's REST, focus on OpenAPI documentation. Inter-service communication clients must implement many things that don't come out-of-the-box: retries with exponential backoff, timeouts. A typical bare-bones gRPC client requires you to manually factor those additional things to make sure you don't suffer from transient errors. Ensure that your unit, integration testing, and end-to-end testing setup is stable and scales with the amount of service-level separations you introduce into your codebase. On smaller projects that use micro-service-based workloads, you would likely default to a shared library with common helpers for instrumenting your observability, communication code in a consistent way. An important consideration here — keep your shared library as small as possible. Any major change forces a rebuild across all dependent services — even if unrelated. Look into observability earlier on. Add structured-JSON logs and create various correlation IDs for debugging things once your app is deployed. Even basic helpers that output rich logging information (until you instrumented your app with proper logging/tracing facilities) often save time figuring out flaky user flows. Evaluate your technical stack that powers your micro-service-based architecture. Invest in developer experience tooling. When you have service-based separation, you now need to think about automating your microservice stack, automating config across both local and production environments. In certain projects, I had to build a separate CLI that does administrative tasks on the monorepository. One project I had contained 15-20 microservice deployments, and for the local environment, I had to create a cli-tool for generating docker-compose.yml files dynamically to achieve seamless one-command start-up for the regular developer. Evaluate your technical stack Focus on reliable communication protocols around service communication. If it's async messaging, make sure your message schemas are consistent and standardized. If it's REST, focus on OpenAPI documentation. Inter-service communication clients must implement many things that don't come out-of-the-box: retries with exponential backoff, timeouts. A typical bare-bones gRPC client requires you to manually factor those additional things to make sure you don't suffer from transient errors. Focus on reliable communication protocols Ensure that your unit, integration testing, and end-to-end testing setup is stable and scales with the amount of service-level separations you introduce into your codebase. Ensure that your unit, integration testing, and end-to-end testing setup On smaller projects that use micro-service-based workloads, you would likely default to a shared library with common helpers for instrumenting your observability, communication code in a consistent way. An important consideration here — keep your shared library as small as possible . Any major change forces a rebuild across all dependent services — even if unrelated. keep your shared library as small as possible Look into observability earlier on. Add structured-JSON logs and create various correlation IDs for debugging things once your app is deployed. Even basic helpers that output rich logging information (until you instrumented your app with proper logging/tracing facilities) often save time figuring out flaky user flows. Look into observability earlier on. To summarize: if you're still going for microservices, you should beforehand understand the tax you're going to pay in terms of additional development time and maintenance to make the setup workable for every engineer in your team. Takeaway: If you embrace complexity, invest fully in making it manageable. Takeaway: If you embrace complexity, invest fully in making it manageable. Conclusion Premature microservices are a tax you can’t afford. Stay simple. Stay alive. Split only when the pain makes it obvious. Premature microservices are a tax you can’t afford. Stay simple. Stay alive. Survive first. Scale later. Choose the simplest system that works — and earn every layer of complexity you add. Survive first. Scale later. Choose the simplest system that works — and earn every layer of complexity you add. Related resources Monolith First — Martin Fowler The Majestic Monolith — DHH / Basecamp Goodbye Microservices: From 100s of problem children to 1 superstar — Segment Eng. Deconstructing the Monolith — Shopify Eng. Domain‑Oriented Microservice Architecture — Uber Eng. Go + Services = One Goliath Project — Khan Academy Monolith First — Martin Fowler Monolith First The Majestic Monolith — DHH / Basecamp The Majestic Monolith Goodbye Microservices: From 100s of problem children to 1 superstar — Segment Eng. Goodbye Microservices: From 100s of problem children to 1 superstar Deconstructing the Monolith — Shopify Eng. Deconstructing the Monolith Domain‑Oriented Microservice Architecture — Uber Eng. Domain‑Oriented Microservice Architecture Go + Services = One Goliath Project — Khan Academy Go + Services = One Goliath Project