If you need production-grade applications running at geographically distributed locations without depending on a central server, and your development talent won't come on-premise, keep reading.

I sat in on a Lexmark talk at a ServiceNow conference years ago. Their challenge was finding shadow IT actively hidden by non-US companies. One subsidiary hid a key server in the men's room to avoid its being inventoried. That story stuck with me because it captures the tension perfectly. Central IT wants visibility. Local teams want to get work done without filing a ticket.

Companies have thrown ServiceNow, SAP, and Oracle at this problem for decades. The results are predictable: bloated licensing, feature gates that force upgrades, and a vendor relationship where the customer is always one contract negotiation away from pain. ServiceNow follows the tradition of hiding the football of licensing, limiting what a licensee has while innovating new products that require new spend.

We are at an inflection point. Ruby on Rails has quietly made a series of innovations over the past few years that make it a rational choice for distributed, multinational companies. Not as a toy. As infrastructure.

Rather than make you read the full article, here is the claim:

SQLite and Litestream give each location autonomy with central visibility. Rails engines let you distribute development without distributing access. An AI-tuned shared style guide ensures code is consistent across teams and geographies. Convention over configuration means AI writes Rails better than it writes anything else, reducing the skill floor for local teams.

The entire stack is open source. Rails is MIT-licensed. SQLite is public domain. Litestream is Apache 2.0. There is no vendor to renegotiate with, no feature gate to hit, no football to find.

For companies that have spent years (and millions) trying to solve distributed operations with enterprise SaaS, it might be worth looking at what Rails quietly built while they were not paying attention.

A couple of years ago, 37signals deployed a Rails application using SQLite in production with Once: Campfire, a self-hosted chat application. In-the-wild reports put it at 500 concurrent users on a $5/month VPS with 2 CPUs and 4GB of RAM. "Concurrent" means active, open connections consuming server resources, not registered accounts. The rule of thumb is 10 percent of a company concurrently consumes a broad resource, so 500 concurrent users serves a 5,000-person company if they share a timezone. Spread across time zones, the math gets even more favorable.

There are billions of SQLite databases deployed worldwide. It is the most widely deployed database engine in existence. No server process. No DBA. A single file. Bulletproof.

Litestream provides continuous SQLite database replication to remote storage. A dozen locations across the US (or the world) each run a self-contained Rails application backed by SQLite. Litestream continuously replicates each database to a central data store. Headquarters gets full visibility into every subsidiary's data without those subsidiaries depending on a central server to function. If the network goes down, the local office keeps working. When connectivity returns, replication catches up. Something happens to the subsidary? Restore from the near-real-time Litestream replica and resume operations on a new server.

This is the opposite of the ServiceNow model. Instead of forcing every location through a central bottleneck, you give each location a self-sufficient application and pull the data to the center. And a network bottleneck. The subsidiary that hid a server in the men's room did so because central IT made local operations dependent on central approval. Remove that dependency and you remove the incentive to hide.

37signals released Upright, an open-source, self-hosted synthetic monitoring system, as a Rails engine. An engine is a miniature Rails application that can be mounted inside a host app. It has its own models, controllers, views, routes, and migrations, all namespaced to avoid collisions. You mount it with a single line in your routes file.

This is the capability that ties the architecture together for companies that subcontract development.

A company with a central Rails application (with a standard user, group, and permissions model) can subcontract development to other companies who deliver features as engines. The subcontractor builds and tests against a well-defined interface. They ship a gem. You mount it. Their code runs inside your application's authentication and authorization layer, but they never see your proprietary business logic, your database schema, or your customer data.

The engine is the contract. The mountpoint is the integration. The host app's auth layer is the security boundary.

For a multinational company, this means your German subsidiary can commission local developers to build a compliance module as an engine. Your Brazilian team can build a tax calculation engine. Corporate mounts them into the central application, tests them, and deploys. The subcontractors never had access to the main codebase. The core app stays stable while capability bolts on from the outside.
 

A Style Guide That Makes AI Write Consumer-Grade Code

37signals released Fizzy, their kanban tool, as open source. Not just a git repo, but with full history: 265 pull requests, code review discussions and commit-by-commit iterations. The community did what the community does. They analyzed both the final source code and the process that produced it, extracting transferable Rails patterns rather than Fizzy-specific business logic. The result was an unofficial 37 Signals Style guide.

Why did anyone bother? Because 37signals ships consumer-grade products with slim, maintainable code bases, and Fizzy was the first time developers could study a real 37signals production application rather than blog posts and conference talks.

I distilled that guide into an AI-digestible standard and fed it to my coding assistant. The difference was immediate. My projects stopped looking like hobby projects. Same AI, same prompts, dramatically better output, because the model finally had a concrete definition of "good" instead of guessing. The code came back with proper concern extraction, thin controllers, rich models, and a working test harness.

For a distributed company, this matters. If your subsidiaries are building Rails applications with a shared style guide, the AI-assisted code from your team in Stuttgart looks structurally identical to the code from your team in Raleigh. That is not aspirational. That is what convention over configuration was designed to produce.


AI Writes Better Rails Than Anything Else

Ruby has long been a programmer-friendly language. That friendliness now pays a different dividend: it is easier for AI to write well.

Rails' philosophy of convention over configuration means there is one right way to do most things. AI models thrive on predictable patterns. When the framework dictates where files go, how routes map to controllers, and how models relate, the AI has less room to invent bad architecture. I know this because I have built multiple personal-use Rails applications using AI alone. Not prototypes. Working applications with authentication, authorization, and production-grade patterns.

This includes adopting the Delegated Type pattern that 37 Signals uses in Basecamp and HEY. A "recording" acts as a pointer to immutable content. When content changes, a new record is created and the pointer is updated. The old version stays intact. You get a full audit trail, efficient copying, and a database that tells the truth about what happened and when. 37signals' Principal Programmer Jeffrey Hardy explained the pattern in detail in December 2025 and I converted to an AI-consumable pattern that runs my web apps.