The most-cited case for leaving the cloud comes from a 60-person company. Read it anyway.

In October 2022, David Heinemeier Hansson published a post explaining why 37signals — the company behind Basecamp and HEY — was leaving the cloud.

The bill behind it was $3.2 million for 2022 (37signals). Not a bill inflated by carelessness: by their account it was already a highly optimized budget, with long-term Reserved Instance commitments and monthly cost tracking. They had played the cost-optimization game properly.

They bought servers, moved seven applications out by the summer of 2023, and published the results as they went. By 2024 the annual bill had fallen from $3.2 million to $1.3 million, and their projected saving over five years was revised upward from $7 million to more than $10 million once they factored in leaving S3 (DHH, October 2024).

The case is cited often, and cited badly in both directions.

What the case actually establishes

Three things, all narrower than the headline.

That cloud pricing at steady-state scale can exceed owning the equivalent hardware by a wide margin. This is not controversial; it follows from the fact that a provider must earn a return on the capital you are declining to deploy.

That the crossover point arrives earlier than most people assume. 37signals is a small company, and the conventional view was that repatriation economics only work at a far larger scale.

And that the savings are realizable without a headcount explosion, at least in their case, with the existing team.

What it does not establish is that this transfers. Their workload is unusually well suited to owning hardware: predictable, steady, not seasonal, with no meaningful elasticity requirement. HEY once absorbed 300,000 signups in three weeks when they expected 30,000 in six months (DHH), and the cloud handled that beautifully — which is the point. The elasticity was worth paying for while the load was unpredictable and stopped being worth paying for once it was not.

Where the numbers come from

The $3.2 million starting point and the $1.3 million 2024 figure both come from 37signals' own posts. Hardware spend appears as around $600,000 in the February 2023 projection (DHH) and about $700,000 in the October 2024 update: the first was a budget, the second the final figure.

Anyone quoting a specific percentage in a business case should locate the primary post it came from before putting it in front of a CFO.

The argument that keeps getting truncated

The other pillar of the repatriation literature is a 2021 analysis from Andreessen Horowitz, a firm whose interests point the other way.

Their case study is Dropbox, which shifted the majority of its workloads to custom-built infrastructure in leased colocation facilities and saved nearly $75 million over two years, with gross margins rising from 33% to 67% between 2015 and 2017 (Dropbox S-1). They then extrapolated across fifty of the top public software companies at an average enterprise-value-to-gross-profit multiple of 24 to 25 times, arguing that around $4 billion of recovered gross profit could correspond to roughly $100 billion of market capitalization across that group.

That is the trillion-dollar-paradox headline. The formulation underneath it is more useful and almost always dropped: you are crazy if you do not start in the cloud, and crazy if you stay on it.

Both halves matter. The argument is about lifecycle stage, not about cloud being a mistake.

What the savings figures leave out

Every published repatriation number is a comparison of bills. Bills are not costs.

Hardware refresh is the largest omission. Servers bought today are an expense again in four or five years, and a five-year saving calculated against a single hardware purchase has quietly assumed one refresh cycle out of existence.

Then the operational roles. 37signals reports doing this without adding staff (DHH). Most organizations with less unusual workloads and less senior engineering will not, and each added role consumes a meaningful slice of the saving.

Then the option value being surrendered. What you lose is not capacity, it is the ability to change your mind cheaply. That is worth little for a steady workload and a great deal for one you cannot forecast.

And finally the reason your bill is high. A high bill often comes from lift-and-shift architectures that were never adapted — workloads running as though they were still in a data center. Repatriating those returns them to where they were designed to run, and does save money. It also forecloses the redesign that would have saved money in either location.

Ask it per workload

The question is not whether to be in the cloud. It is which workloads have become predictable enough that elasticity is no longer worth its premium.

That is a per-workload question with a defensible answer, and almost nobody asks it that way, because the debate is conducted as an identity position. The organizations getting this right are moving specific things — steady-state compute, bulk storage, backup — while keeping elastic and experimental work where elasticity is cheap.

Before running the numbers, one honest check: is your bill high because the cloud is expensive, or because you moved a data center into it without changing anything? If the second, repatriation will work, will be reported as a success, and will have solved the wrong problem at considerable expense.

Related Reading

• Cloud Cost Management & FinOps
• Cloud Infrastructure & IaaS
• Cloud Migration & Modernization Platforms
• Server Virtualization Platforms
• Technical debt was never about bad code. That is the whole point of the metaphor.
• Knight Capital lost $460 million in 45 minutes because of code it stopped using in 2003
• Amdahl’s Law was written to argue against parallel computing. Now it is used to plan it.
• IT Budget Optimization: A FinOps Framework for Technology Leaders
• Cloud Migration Playbook: From Workload Assessment to Production