How Lendsqr saved 90% on infrastructure cost

There’s a talk DHH gave that a lot of engineers passed around last year. David Heinemeier Hansson, co-founder of Basecamp, creator of Ruby on Rails, and the kind of person who also races cars at Le Mans for fun, had spent years writing large cheques to AWS. Then he stopped. He documented the whole thing, the numbers, the reasoning, the migration, and mentioned Hetzner as the provider that made the economics work for them.

At the time, we read it and moved on without acting on it.

A few months later, one of our oldest customers came to us with a specific problem. They were spending between $5,000 and $8,000 every month running their core banking stack on AWS and wanted to know if there was a better option. We went back to that DHH piece, looked seriously at Hetzner, drew up a migration plan, and moved them over. It took longer than we expected, as these things usually do, but when it was done, their monthly infrastructure bill had dropped to $700, with no change to their workload or transaction volumes.

That outcome sat in the back of our heads for a while.

The migration and what it cost afterwards

By the end of that year, Lendsqr was spending close to $30,000 a month across GCP and AWS. We serve 3.5 million customers with transactions running constantly across the platform, and the infrastructure spend had crept up over time the way it does when you’re focused on building product and the cloud bill becomes background noise you stop questioning.

But we’d just helped a customer cut their infrastructure cost by roughly 90%. The question that followed was uncomfortable in a useful way: why hadn’t we done this for ourselves?

We decided to find out.

The migration we ran for our customer was bare metal on Hetzner. For ourselves, we chose Hetzner’s cloud infrastructure instead. Part of that was geography; we wanted some services to remain US-hosted, and cloud gave us more flexibility there than bare metal would have.

Three engineers ran the migration: Froggy, Feranmi, and Kayode. The stack we moved to uses Kubernetes for orchestration, with K3S and Rancher handling the cluster management layer. We also brought in Coolify to manage a subset of services, though we’re working toward consolidating everything into Kubernetes.

It took three hard and long weekends. The timing wasn’t clean either as we were also finishing a consolidation of our core systems in December, which meant that for the first time, almost all our services were landing in one place simultaneously. Some things broke during that process. We found dependencies we hadn’t fully documented. There were late nights, although none of that is unusual for a migration of this scope, but it’s worth saying plainly rather than glossing over it.

When the first full month of billing came through after the migration, our infrastructure cost was $1,113. Our previous spend on AWS alone had been over $1,500 a month, before counting GCP, with the combined total sitting closer to $30,000. But the number that really put things in perspective was a specific line item we noticed during the process: the cost of maintaining two EBS snapshots on AWS was higher than running all of our database services on Hetzner, primary instances and replicas included. That kind of comparison makes you want to go back through every other service on the cloud bill with fresh eyes. 

What stayed and what changed

This wasn’t a total departure from AWS. There are services where it genuinely earns what it charges, and we kept those. SES stays because we’ve evaluated alternatives and haven’t found anything that performs as consistently for email delivery at our volumes. S3 stays for storage. AWS Rekognition currently runs our KYC pipeline, and we’re still having internal conversations about whether a viable alternative exists there without landing anywhere definitive yet. The services we migrated were the compute-heavy workloads where we were paying managed service premiums for things our team could run without material reliability risk. The goal was to stop paying for convenience we no longer needed.

What changed was the operational responsibility that came with moving off managed services. On AWS, a lot of the maintenance work is abstracted away. Managed RDS handles database patching. CloudWatch handles log aggregation. You pay for that abstraction in your bill, and it’s a real trade-off. When you move off managed services, those responsibilities shift to your team.

Our databases are now fully self-managed, meaning we handle updates, replication configuration, and backups ourselves. Logging that previously went into CloudWatch now runs through Grafana and Sentry, which we use for observability, is self-hosted. All of it requires regular engineering attention.

For teams without strong DevOps depth, this is where the savings can get eaten back. The operational overhead is tangible, and underestimating it is how migrations like this go sideways. We were in a reasonably good position because we’d been self-hosting a range of open source tools for a while before this migration happened. Sentry, Metabase, n8n, SonarQube, Typesense, so we already had internal processes for keeping these systems patched and updated. We maintain a deliberate approach to version management: always current on security patches, but not chasing the absolute latest release of anything in production. That discipline existed before we touched the infrastructure migration, and it made the transition considerably more manageable.

What have we truly saved

At roughly $1,100 a month versus $30,000 a month, the annual delta is approximately $144,000. For context, companies of comparable size and transaction load to ours typically spend at least $50,000 a month on infrastructure. Against that baseline, the gap is even larger.

That figure is real capital that funds engineering headcount, product work, and the operational runway that determines how much room a company has to move and make decisions.

We’re not suggesting this is replicable for every company. The prerequisites are meaningful; you need Kubernetes competency that goes beyond theoretical familiarity, engineers who can own infrastructure operations without a managed service underneath them, and internal processes mature enough to handle security patching without introducing instability. If those things aren’t in place, the migration creates risk that the cost savings don’t offset.

But if they are in place, the economics deserve a serious look. Cloud providers gave us real value at the stage when we needed flexibility more than cost efficiency. The question worth asking periodically is whether that trade-off still makes sense at your current scale. For us, the answer turned out to be no, and doing something about it saved us $144,000 a year.