Ruby remains a strong fit for product teams that value speed, readability, and staying power. The language was built for shipping products, not fighting your tools, and Rails 8 has only sharpened that edge — cleaner defaults, fewer dependencies, and opinions in the places that matter.
A decoupled SPA-and-API architecture solves a specific problem: coordination across teams. When a frontend group and a backend group ship on separate cadences, the API contract becomes the interface that lets each side reason about its own slice in isolation. That boundary earns its keep, and at sufficient scale it is the correct call.
But architecture should follow the constraint, not the fashion. Most systems are not built by two specialized teams behind a contract — they are built by one or two people who own the whole stack. For that profile, a hard API boundary isn't decoupling; it's surface area. You've doubled the deploy pipeline, the auth flow, and the failure modes to satisfy an org boundary that doesn't exist. The cost is real and the benefit is theoretical.
This is where the Rails monolith stops being a compromise and becomes the optimal design. One model, one repository, one deploy. The controller, the persistence layer, and the view sit within arm's reach, and a schema change ships alongside the page that renders it in a single commit.
The modern stack reinforces the point. Hotwire and Turbo cover the interactivity most applications actually require without standing up a second application to do it. The Solid trio — Queue, Cache, Cable — runs background work, caching, and websockets on the primary database instead of a fleet of supporting services. Kamal deploys to a plain server with a config file, no control plane required. Each is operational surface area the small team simply doesn't carry.
The principle is straightforward: match the architecture to the organization. Decoupling answers a coordination problem. If you don't have that problem — and most teams, most of the time, don't — you are paying to solve one you'll never encounter. After a decade, that calculus still favors Ruby for the work most of us are actually doing. In 2026, that isn't nostalgia. It's just the right call.