$10 million. That’s the five-year saving 37signals anticipate from leaving AWS.
In 2022 David Heinemeier Hansson — CTO of 37signals and creator of Ruby on Rails announced his company was leaving the cloud in a fairly public way. By mid-2023, they’d moved the majority of their infrastructure off AWS and onto owned hardware.
Cloud advocates called it reckless. Cloud sceptics called it vindication. Most people argued about it on Twitter without reading the details.
What actually happened, what translates beyond 37signals, and what doesn’t apply to your situation:
What they did
37signals runs Basecamp (project management) and HEY (email). Mature products, stable traffic, predictable patterns. Their AWS bill had grown to roughly $3.2 million per year.
They didn’t move everything. Surgical approach:
Moved off cloud: primary compute, databases (MySQL, Redis), search (Elasticsearch), storage (file uploads, assets).
Kept on cloud: edge computing and CDN, some auxiliary services, disaster recovery and burst capacity.
They bought Dell servers — roughly $600k in hardware — and colocated in two datacenters. Expected to recoup the cost in six months.
Monthly infrastructure dropped from ~$267k on AWS to ~$87k on owned hardware (including colo, bandwidth, hardware amortisation, and additional staffing). 67% reduction.
Why it worked for them
Predictable, steady-state workloads. Basecamp and HEY don’t have Black Friday spikes. Consistent traffic, gradual growth. They were paying for elasticity they never used.
Significant scale. At $3.2M/year, even a 50% reduction justified a dedicated infrastructure team.
Deep operational expertise. They’ve been running internet services for over 20 years. They had (and hired) engineers who could manage bare metal.
Simple architecture. Monolithic Rails apps, traditional databases, request-response patterns. Not a microservices mesh with 200 Lambda functions.
Willingness to invest upfront. $600k in hardware requires capital and confidence. They’re profitable and cash-rich.
What translates to mid-market companies
You’re probably not 37signals, maybe you have a much smaller staff and budget and/org cloud spend. Regardless of your size there are some lessons you can apply to your business:
The steady-state test
Most useful question: what percentage of your cloud compute runs at steady state?
If the answer is “most of it” — app servers, databases, background workers running 24/7 at 30–60% utilisation — you’re paying for elasticity on workloads that don’t need it. The “bursty” workloads that justify cloud pricing are typically a small fraction of total spend. Many companies don’t even build their infrastructure in a way that allows it to exploit this elasticity!
You don’t need to move everything
37signals kept their CDN and some services on cloud, which makes absolute sense for their workloads. The goal isn’t to eliminate cloud, it’s to stop using it for workloads where it’s not the right tool for the job.
A sensible pattern is to shift steady-state compute and databases to dedicated hardware. CDN, edge functions, and burst capacity stay on cloud (genuine value). Dev and CI/CD on dedicated hardware (easy win, low risk).
Hardware is surprisingly cheap
37signals spent $600k to replace $3.2M/year in costs which meant that they were able to cover costs in a few months.
At smaller scale the same economics can be used. A £3,000 Hetzner or OVH dedicated server provides the same compute as £500–£800/month in AWS instances. Even with the recent RAM and SSD shortages caused by demand it can be easy to get savings in under a year post migration.
Operational overhead is manageable
Biggest fear: “who manages the servers?” 37signals hired two additional ops engineers, which is appropriate for their scale.
For a mid-market company moving a portion of workloads, you typically don’t need additional headcount. An existing senior engineer can manage it part-time with:
- Terraform for provisioning (works with Hetzner, OVH, most providers)
- Ansible for config management, security hardening, deployment
- Prometheus + Grafana for monitoring (often better than CloudWatch, zero marginal cost)
- **pgBackRest ** for backups (automated, tested, reliable)
Real overhead is added, but much of it is a one time investment in setup cost, not a full-time job for a moderate infrastructure.
What doesn’t translate
Scale matters. If you’re spending £5k/month on cloud, the absolute savings might not justify the effort. Economics usually start making sense at £10k–£20k/month and above.
Architecture complexity. 50 microservices on ECS with event-driven patterns, managed queues, and serverless? Your migration complexity is going to be significantly higher. Not impossible, but the ROI calculation needs more engineering time and the end result might not justify a migration.
Organisational readiness. If your engineering team has only ever used managed services, there’s a learning curve. Factor in training and the inevitable early mistakes, or decide on how to partner with a Managed Service Provide to bridge the gap.
Growth trajectory. If you might 10x in the next year, cloud auto-scaling has genuine value. Plan for future scale, not just current costs.
How to figure out if this applies to you
Know your numbers. What do you actually spend, broken down by service? What is your projected future growth?
Classify your workloads. Steady-state or bursty? Cloud-native or portable? HA requirement or acceptable-downtime?
Model the alternative. For steady-state, portable workloads, price equivalent dedicated hardware. Include operational costs.
Calculate break-even. Under 6 months = strong candidate. Under 12 = worth serious consideration. Over 18 = probably not yet.
Start small. Move a non-critical workload first. Staging environment. CI/CD pipeline. Monitoring stack. Build confidence before touching production.
The takeaway
37signals proved that the default assumption that cloud is always the best option can be expensive and often wrong. They ran the numbers and found they were overpaying by millions, and made a rational business decision.
Every company spending serious money on cloud should do the same analysis, and many will conclude cloud is the right choice. But that conclusion should come from arithmetic, not inertia or the perception of being stuck on a platform.
The Platform Fit Verdict applies our analysis to your infrastructure — what your workloads would cost on dedicated hardware vs cloud, with the numbers to make the decision.