Go to the profile of Jay Meistrich
Jay Meistrich
Co-founder of Moo.do. Nomad. Photographer. Skier. Lover of Minions.

Serverless: Bootstrap your startup by only doing half of the work

When my co-founder and I started Moo.do, our goals seemed far too ambitious for the two of us alone. We wanted to build an email client, todo list, kanban board, and calendar — all working together in one app. With real-time collaboration on all desktop and mobile platforms.

Of course, that much work would be nuts for just two people.

We were passionate about the front-end user experience, but to make our product work we would also need to build a large scalable backend. This in itself would be a huge amount of work, so we would need to hire developers to build the backend and manage the servers.

To afford that, we would be stuck investing months into getting VC funding. And then it would take a few more months to hire employees and ramp them up.

And all of that would be before we could start validating whether customers would even like the product.

Fortunately, we started right when cloud databases like the Google Drive Realtime API and Firebase were launching. We realized we could skip the backend completely, save a huge amount of time and money, and bootstrap the company ourselves.

Serverless

Serverless is the hip new trend in web development these days. The idea is that your server code magically runs in the cloud while the cloud provider manages and scales their servers behind the scenes. It’s a great way to reduce the work required to build a web app. But we took it even further: Moo.do is fully client-side and we use free external services as our backend.

Ok, that’s actually a little bit of a lie. We do have a small server just for minor user account details like settings and billing, but that’s it.

This is an enormous undertaking, and it would have been impossible if we had to build the backend required for large-scale data storage and real-time collaboration as well as the web and mobile apps.

How it works

All of a user’s private data is stored in their personal Google Drive account and we use client-side APIs for everything:

When you launch the app, everything is downloaded and stored locally in Application Cache so that it can work offline and to speed up load time. It loads any local data stored in IndexedDB and then connects to the Google Drive Realtime API to set up the real-time sync, and syncs with the Gmail, Google Calendar, and Google Drive APIs. And finally it quickly pings our server to confirm the user’s premium account status.

In typical web apps, most of that would happen on the server instead of on the client. Doing it all client-side might sound crazy, but I’ll explain why:

The Benefits

Get started quickly

We added real-time collaboration to our initial prototype in just a few days with the Google Drive Realtime API. This allowed us to quickly build a working product to prove the idea. Otherwise, we would have had to invest a huge amount of time in building a real-time collaboration system before we could even validate whether people like the product.

Save money

These services and APIs are free, so we’re running at near zero variable costs. We don’t have any extra money to waste since we’re bootstrapping our company, so lower cost extends our runway.

A typical downside to a freemium business model is that the free users can drive up costs. But in our case, free users cost us almost nothing.

Hire less people

We don’t need backend engineers because we have no complex backend to engineer. And we don’t need systems administrators because we have no systems to administrate.

We are able to build this as just two founders with no employees and no VC funding.

Less work and therefore less bugs

Building a backend for real-time sync and collaboration would be a tremendous amount of work. Ain’t nobody got time for that, so we skipped it. And a heavily used API that’s well tested by Google is going to have less bugs than code we write from scratch.

Of course, every API or service needs some work to fit into the app. We have a lot of client-side integration code, like conflict resolution to support offline usage, but everything else is taken care of by Google.

Huge performance gains

Moo.do is a static page, meaning we cannot send user data with the initial download, so everything has to be loaded by JavaScript. This might sound like a downside, but it’s actually great for performance, for two reasons:

  1. Offline caching. When the page loads from Application Cache or Service Worker (the new hotness), it completely skips the whole download process. This can shave many hundreds of milliseconds off your load time, depending on the user’s connection speed. It also saves bandwidth costs (for you and your users) since files are only transferred when they are updated.
  2. Serve assets from a CDN. Since you don’t need any server-side processing to generate the page, you can host the page and all your assets on a CDN (Content Delivery Network), which is much faster and easier than geographically distributing your own servers.

Infinite scaling

Because we’re running our backend almost entirely on Google services, we’re able to run at Google scale. We could gain a million new users overnight and everything would be fine. We don’t need to throttle signups or worry about being taken down by a Reddit Hug of Death.

No data or passwords on our servers

We use Google OAuth to sign in, which has the huge security advantage that we never receive a user’s actual password.

All items, tasks, and attached files are stored in each user’s personal Google Drive account. Gmail and Google Calendar are synced completely client-side, which means that emails and appointments do not pass through and are never stored on our servers.

Not storing users’ private data on our servers protects their privacy and limits their potential exposure to hacks.

So in conclusion, everything is great and there’s no downsides.
Ok, that’s another lie. Giving up control of our backend does have some drawbacks.

The Drawbacks

Dependency on Google

Google has been known to shut down services. This presents a risk, but they typically give a warning beforehand and a long window to migrate away. They are investing heavily in Google Drive, and we don’t see Gmail going away anytime soon. The dependency on Google is a risk, but we feel confident that these services will stick around.

Bugs in APIs

There’s always a risk that a new bug will appear that is out of our control to fix. The Google Drive Realtime API had some issues in its early days, but the developers were responsive and fixed bugs quickly, and it has been stable for the past two years. Based on their track record of stability and responsiveness, we feel safe.

Static page makes A/B testing hard

The only true downside of a static page that we’ve found is that it’s harder to A/B test. There is no server to decide whether to send the user A or B, so we have to send the user both A and B and then display the right one in client-side JavaScript.

Google Drive Realtime API is JavaScript only

If you need to access your data from a native app, the alternative solutions listed below might be better for you. We’re ok with this limitation because we’re heavily invested in JavaScript — even our iOS and Android apps are mobile web apps. That might sound crazy, but mobile web can actually be fast. That’s a topic for a future post…

Serverless technologies

aI’d love to hear your thoughts in the comments below, or talk to me on Twitter. And if you liked this article please click the ❤ below to help me share it. Thanks!