when-NOT-to-use-microservices

What problem does it solve?

Rails teams frequently jump into microservice migrations based on hype or perceived best practices, only to incur massive operational overhead, slowed velocity, and costly rework when the migration fails to deliver expected benefits. This Skill exists to push back on premature microservice adoption and guide teams toward more sustainable, low-friction architecture choices.

Core Features & Use Cases

• Evidence-based pushback: Counter-arguments for the most common bad reasons to adopt microservices, including small team size, Kubernetes usage, and "messy monolith" assumptions.
• Structured decision framework: A 6-question sequential gate to objectively evaluate if your team is truly ready for microservices, with clear thresholds for each criterion.
• Modular monolith guidance: Step-by-step instructions for restructuring your Rails monolith with packwerk, packs, or engines to get 90% of the team-scaling benefits of microservices at 5% of the operational cost.
• Use Case: A 15-person Rails team considering splitting their monolith to "scale" can use this Skill to get a data-backed recommendation to stick with a modular monolith, plus a concrete plan to improve their existing codebase boundaries first.

Quick Start

Request an evaluation of whether your team should adopt microservices, along with a tailored recommendation and actionable next steps for your Rails codebase.