A 6-person startup is deciding whether to build their new product as a monolith or as a set of independently deployed services from day one. What concrete reasons would favor starting as a monolith, and what signals would later tell them it's time to reconsider?

## Two independent arguments The case for a small, early-stage team starting with a monolith rests on two independent arguments: 1. **team-size economics**; 2. **domain uncertainty**. Both point the same direction for a 6-person startup with an unproven product. ## Team-size economics On team-size economics: microservices exist to let independent teams deploy, scale, and operate their piece of a system without coordinating with every other team, and to let each service scale to its own load pattern independently. Both of those benefits require the coordination cost they solve to already exist — you need multiple teams stepping on each other, or genuinely divergent scaling needs, for splitting into services to pay for itself. Six engineers sitting in one Slack channel (or one room) do not have a cross-team coordination problem; they can just talk to each other, agree on an interface inside the codebase, and merge. Meanwhile, choosing microservices from day one imposes real, immediate costs regardless of team size. You now need: - **service discovery**; - **network-failure handling** (timeouts, retries, circuit breakers) for calls that used to be simple function calls; - **distributed tracing** to debug a request that spans multiple services; - separate **CI/CD pipelines** and monitoring dashboards per service; - some strategy for **cross-service data consistency** (sagas, outbox patterns) in place of a single database transaction. For six people, standing up and maintaining that infrastructure is itself a significant fraction of the team's total capacity — capacity that, pre-product-market-fit, is far better spent building and testing the actual product. ## Domain uncertainty On domain uncertainty: service boundaries are supposed to track real, stable seams in the business domain — the places where two areas of the system genuinely change for different reasons and at different rates. An early-stage startup, by definition, doesn't yet know where those seams are; the product is still being discovered through customer feedback, and what looks like a natural 'billing service' boundary in week one may turn out to be tangled up with 'subscription' concerns that were wrongly assumed separate. | Boundary placed badly | What undoing it costs | |---|---| | A class boundary inside a monolith | Getting it wrong is a same-day refactor, caught by the compiler, and safely undoable. | | A service boundary | Getting it wrong means the wrong data now lives behind the wrong network API, other code has already started depending on that API's shape, and un-splitting or re-splitting two live services with real traffic and real data is a materially harder, riskier migration than moving code within one codebase. | Premature service decomposition effectively locks in a guess about the domain before you have the evidence to make that guess well. ## The signals that it's time to reconsider The signals that it's time to reconsider are concrete and specific, not a vague sense that 'the codebase feels big.' 1. **The first is divergent scaling needs.** If one component (say, a video-transcoding pipeline) needs to scale to ten times the instance count of the rest of the application under load, forcing the whole monolith to scale along with it wastes resources scaling parts that don't need it — that's a legitimate, measurable reason to extract that component. 2. **The second is organizational.** Once distinct, stable teams genuinely own distinct areas of the product and are being blocked by a shared release train (the deployment-simplicity cost discussed elsewhere — one team's broken build blocking another team's urgent fix), splitting along those now-real team boundaries starts to pay for itself. 3. **The third is a hard technical or compliance constraint.** A component that must run in a different runtime, meet a stricter compliance boundary (e.g., PCI scope for payment handling), or use a fundamentally different technology than the rest of the stack is a legitimate forcing function regardless of team size. 4. **The fourth is when the shared build/test pipeline has become the actual bottleneck** on how fast the team can ship — measured, not felt, via degrading deploy frequency and lead time for changes. ## Shopify's trajectory A well-known real-world pattern following exactly this trajectory is Shopify, which built and scaled its core commerce platform as a Ruby on Rails monolith well past the point most conventional wisdom says you should have split it, specifically because the team judged that domain boundaries stayed genuinely unclear for a long time and the shared-transaction, shared-deploy simplicity kept outweighing the coupling costs; where they did eventually need independent scaling or isolation (certain high-load or compliance-sensitive components), they extracted those specific pieces rather than decomposing the whole system upfront. That's the general shape of the right call: start monolithic when the team is small and the domain is unproven, and extract specific components later in response to specific, measured pressure — not on a fixed schedule or because microservices are perceived as the more modern default.