In my previous article, I discussed how vendor lock-in emerges from accumulated platform dependencies. Modern development platforms are convenient, but that convenience often comes with architectural constraints that only become visible when change becomes necessary.
There is another path. It requires more deliberate choices, but it offers something increasingly rare: genuine independence.
The Lesson Is a Decision Model, Not a Shopping List
The wrong way to learn from 37signals is to replace every managed service with the latest tool from their ecosystem. The useful lesson is to examine which capabilities are strategic, which dependencies create disproportionate exit costs, and which operational responsibilities a team is genuinely prepared to own.
I use four questions when reviewing a Rails system through this lens:
- Where does product behavior live? Business rules should be visible in code and tests rather than scattered across vendor dashboards.
- Can the team operate the chosen stack? Ownership without observability, backups, patching, and recovery practice is only hidden risk.
- What is the smallest sufficient component? A database-backed queue may simplify one workload while remaining the wrong choice for another.
- Is the change reversible? A staged replacement with measurable exit criteria is safer than an ideological platform migration.
| Area | Keep the managed service when… | Consider greater ownership when… |
|---|---|---|
| Deployment | The team gains more from platform operations than it pays in cost and constraints | Pricing, limits, or proprietary workflows block delivery |
| Jobs and cache | Workload and reliability needs justify specialized infrastructure | Operational complexity exceeds the real workload |
| Monitoring | The service provides actionable coverage the team uses | Cost grows while critical product journeys remain opaque |
| Data | Managed operations reduce real database risk | Export, residency, access, or pricing threatens product control |
The goal is not maximum self-hosting. It is a system whose important boundaries are understood, whose failure modes are observable, and whose dependencies remain conscious choices. A ten-person product company and 37signals should not have identical infrastructure, but both can insist that convenience does not erase ownership.
How I would introduce the stack
Start with an inventory rather than a migration. Map each dependency to its purpose, monthly cost, operational burden, data held, switching cost, and realistic alternative. Choose one boundary where simplification has a measurable outcome, such as shorter deploys, fewer moving parts, lower recovery time, or reduced spend. Run the new component alongside the current path when possible, define rollback conditions, and document what the team learned before changing the next layer.
That approach turns the ownership philosophy into engineering management: small decisions, explicit evidence, and preserved optionality.
37signals has been walking this path for two decades. Their approach is consistent: identify a real problem, build a solution that works for them, and release it as open source. The result is an ecosystem of tools that provide an alternative to the platform dependencies most teams accept as inevitable.
The pattern
Every major 37signals open source project follows the same origin story. They encounter a limitation or frustration in their own work, they build something to address it, and then they share it.
Consider the timeline:
- DHH needed a web framework that matched how he thought about building applications. Ruby on Rails emerged and changed how an entire generation learned to build for the web.
- They wanted the responsiveness of single-page applications without the complexity of React or Vue. They adopted and developed Hotwire (Turbo + Stimulus) as an alternative architecture.
- They needed native mobile apps for Basecamp and HEY without maintaining separate Swift and Kotlin codebases. Hotwire Native extended their web-first approach to iOS and Android.
- They wanted to deploy on their own hardware without Kubernetes complexity. Kamal made Docker deployments via SSH straightforward.
- They realized Redis, Sidekiq, and Memcached could be replaced by the database for most workloads. Solid Queue, Solid Cache, and Solid Cable demonstrated that modern SSDs change the performance equation.
- They needed a faster HTTP/2 proxy. Thruster filled the gap.
- DHH switched to Linux - driven partly by frustration with Apple’s ecosystem policies - and needed a proper development setup. Omakub became the standard for Ubuntu, while Omarchy brought the same philosophy to Arch Linux for more adventurous users.
And most recently:
- Pingdom did not provide the monitoring flexibility they needed. Upright was born.
None of these projects started as products. They started as internal tools that solved real problems in production.
Upright - the latest example
Upright illustrates the pattern clearly. 37signals had been paying Pingdom for years to monitor Basecamp, HEY, and Fizzy. The frustrations accumulated:
- They could not customize checks to their needs.
- They could not control which regions tests ran from.
- They could not run authenticated browser flows without paying extra.
- The system was a black box - probes would fail, trigger alerts, then resolve before anyone could investigate.
So they built their own. The stack is predictable - Rails, SQLite, Solid Queue, Kamal. Their five-site production deployment costs around $110 per month total. A minimal two-site setup can run for under $20.
Upright is now MIT-licensed and available on GitHub. The pattern repeats: problem, solution, open source.
Why ownership matters
DHH has been explicit about the reasoning behind this approach. In his words: “The cloud industrial complex has convinced everyone that running servers is impossibly hard. It’s not. We did it for decades before AWS existed.”
37signals exited the cloud in 2022, purchasing their own Dell servers and deploying them to data centers. The estimated savings were $7 million over five years. But DHH framed the decision as more than financial:
“It’s also about what kind of internet we want to operate in the future. It strikes me as downright tragic that this decentralized wonder of the world is now largely operating on computers owned by a handful of mega corporations.”
This philosophy extends beyond infrastructure to the entire development stack. Each tool they release reduces a dependency. Solid Queue means you do not need Redis and Sidekiq. Solid Cache means you do not need Memcached. Kamal means you do not need Kubernetes or expensive PaaS platforms. Upright means you do not need Pingdom or Datadog for synthetic monitoring.
The accumulation of these choices creates architectural independence. When your job queue, cache, WebSocket backend, deployment system, and monitoring all come from the same ecosystem - and that ecosystem is open source - you control your own infrastructure destiny.
The SQLite moment
Rails 8 embodies this philosophy. The Solid adapters (Queue, Cache, Cable) are now the default in new Rails applications - not a niche experiment, but the new Rails standard. They can all run on SQLite, using the same database as your application.
Existing applications do not need to adopt the whole stack at once. A safe Rails modernization starts by measuring the current database, jobs, cache, deployment flow, and operational risks, then introduces simpler components only where they remove real cost or failure modes.
The technical premise is straightforward: SSDs and NVMe drives are fast enough that the database can handle workloads that previously required specialized in-memory systems. For many applications, this eliminates entire categories of infrastructure.
This is not about SQLite being universally superior. It is about having options. A small team can start with a single SQLite database and scale to PostgreSQL when genuinely necessary. The architecture does not lock them into decisions made when the application was smallest.
The ecosystem today
The collective output from 37signals and the broader Rails community forms a coherent stack:
| Concern | Traditional Approach | 37signals Ecosystem |
|---|---|---|
| Frontend reactivity | React/Vue SPA | Hotwire (Turbo + Stimulus) |
| Mobile apps | React Native / Native | Hotwire Native |
| Job processing | Redis + Sidekiq | Solid Queue + database |
| Caching | Redis / Memcached | Solid Cache + database |
| WebSockets | Redis pub/sub | Solid Cable + database |
| Deployment | Kubernetes / PaaS | Kamal + Docker + SSH |
| SSL/HTTP2 termination | nginx/Apache configs | Thruster |
| Synthetic monitoring | Pingdom / Datadog | Upright |
| Infrastructure | AWS / GCP | Own hardware or VPS |
Each component is optional. You can use Solid Queue with PostgreSQL and deploy to Heroku. You can use Kamal to deploy to DigitalOcean droplets. The tools compose rather than requiring full adoption.
But taken together, they offer something unusual: a path to production that does not depend on any single vendor’s continued good behavior or pricing decisions.
Ruby is more alive than ever
The narrative that Ruby is dying persists despite evidence to the contrary. The Rails 8.1 release involved over 500 contributors across 2,500 commits. Companies including Shopify, GitHub, Airbnb, and Stripe continue to run substantial Rails applications.
The forward momentum is evident in the tools themselves. This ecosystem continues to produce innovative solutions like Hotwire, Kamal, the Solid adapters, and Upright. These are not maintenance releases or minor improvements. They represent genuine innovation in how web applications are built and deployed.
37signals ships products built on this stack every day. Basecamp and HEY serve paying customers. The tools they release are not theoretical - they work in production under real load.
Choosing independence
The 37signals approach is not for everyone. Running your own servers requires operational knowledge - this level of independence demands stronger DevOps competencies than full cloud outsourcing. Using less common tools means less Stack Overflow coverage training data for AI assistants. Choosing the road less traveled has real costs.
But the alternative has costs too. Platform dependencies accumulate silently. Pricing changes without notice. APIs deprecate. Services shut down. The vendor lock-in I described in my previous article is not hypothetical - it is the default outcome of convenient choices made without considering long-term implications.
What 37signals offers is proof that another path exists. You can build modern web applications without surrendering architectural control. You can deploy without Kubernetes. You can process jobs and cache data without Redis. You can monitor your services without paying enterprise monitoring prices.
The tools are available, open source, and production-tested.
37signals has made their choice visible through twenty years of open source contributions. The choice for the rest of us remains open.
An earlier version of this article was published on Visuality.pl blog.