Why building a self-hosted SaaS is harder

Summary

In the 90s, we flew in technicians to install Oracle databases in server basements. Today, Supabase spins up a backend, in seconds, for free.Over the past 30 years, software has gotten faster, cheaper and easier in almost every way.Some engineers might miss 24-month cycles of tranquil coding, but nobody wants to do code reviews over email or contort software to run on a 10 year-old server rack your eighth-biggest customer is still using.As an open source SaaS startup, we need to be able to do both: Ship quickly while also offering a self-hosted version.This makes shipping updates harder because customer instances are a black box. We have no way to know what jobs a customer has running. This is especially difficult because no two customers use Lago the same way. One customer might aggregate usage data in real-time while another does so monthly. Even low-risk fixes like renaming a database column can break a billing run when a job is currently using that data. But as a startup, we need to ship quickly and frequently. In this piece, I want to explain how we balance the two: Shipping quickly without neglecting self-hosted customers. Before the details, let’s answer a valid question: Why go through the pain of offering self-hosting?C’mon, it’s 2025. Why even offer self-hosting?Just about everything has moved to the cloud. If you shut down AWS, Azure and GCP, you’d shut down the software business. This has made everything available everywhere, obviated in-house software maintenance, etc. But it also comes with trade-offs: You can’t extend/integrate cloud software beyond what APIs allow you to do. If a cloud vendor has a security issue, you now have a security issue. If a vendor fails/gets sunset by an acquirer, their software disappears. All of these are fine for much of B2B SaaS. Take a tool like Miro. It doesn’t require deep integrations to be useful. You’re not storing critical data there. If Miro vanishes over night, it’s an inconvenience.The opposite is true for infr...