In 2008 when I started working in what would become my SaaS company, one of the major concerns of my customers was if E-belle (my product) would work offline. The Internet was not great in brazil, and mobile networks were slow and expensive, making them not trust they would have their data when needed. I did many unsuccessfully POCs to make that a reality and needed to come up with many alternatives to convince my customers it would be safe to use a pure web product.

Nowadays (in 2022), those questions don’t even come up anymore when we present the product to new customers because everyone got so used to having the Internet all the time for an affordable price. This process was great, primarily for web developers. Nevertheless, we lost something in the process of going to the cloud.

The problem of running small SaaS

My number one source of stress about running a SaaS business is outages. Even “word-class” companies experience outrages (Google is back online after users around the world reported a brief outage) and they are always stressful and time-sensitive issues.

One can make its software very robust and have as few outages as possible

• Run redundant service in multiple regions within a cloud provider.
• Use multi-cloud providers, running multiple instances of the same service in GCP, AWS, and Azure.
• Avoid using SaaS and looked in systems so you can run the same infra in any cloud provider.

I guarantee you. It will be complex and costly. You must frequently test the redundancies and fallbacks to ensure you will not be surprised when the time to use them comes. And yet you may be surprised by an unexpected problem one day that will require manual intervention in your service.

Imagine yourself running a solo SaaS and never being able to go offline for an extended period. Or get stressed every time you pick a long flight.

First, I don’t recommend running a SaaS business solo for a long time. Once you start onboarding customers, you should bring at least one more person to assist, even if it is only with customer relationships or support.

But doing a Local first SaaS may be a response to that problem. In 2008 when I started building Ebelle, it seemed hard to make it “Local first.” But a few years later, when I became a Mobile developer, I had to build a robust synchronization engine because offline was the only option we had if you wanted to make any practical mobile application.

Now there seems to be a movement in the industry motivated partially by a real need for users to own their own data and recent academia research that is making it less painful.

Local first means your users can still work even if your server is down for a small amount of time for any reason, which means the users can also jump on an airplane and decide to review/update their price table or check out their sales commissions if they want.

It benefits both sides of the software economy, and I am willing to spend some time making that option more effortless and popular. Nun-db will have a play into this, stay tuned.