Modular SaaS primitives

Epistemic status: definitely half-baked

Here’s an idea I’ve playing with recently:

In 5 years most common app features and functionality of SaaS apps, such as reports, auth, in-product notifications, and so on will have drop-in open-source backend implementations in Python and Node.js, with associated frontend screens.

Auth

I chatted recently with a startup doing this for auth called SuperTokens. Their architecture is incredibly interesting.

• There are three layers: frontend code to run in your client, API code to run on your server, and storage that can either happen in your database or their managed service.
• The backend code is in Node, so it’s easily embeddable in a lot of stacks. Because the code runs in your codebase, user flows are native to your domain rather than sent off to Auth0 or wherever.
• And the storage can happen either in any SQL database or their managed service. Typically control planes are more in infra but this isn’t infra, it’s application functionality.

Reports

Auth is a good early example, because every app needs auth, auth is universally a pain (social sign-in! storing OAuth tokens! reset password flow!) and involves writing a lot of boilerplate code. There are good SaaS alternatives, like Auth0, but they can be pricey.

Where this could get really interesting is that there are common features where the wheel is constantly reinvented.

I started a good discussion on Twitter last week about this centered around “reports” as a feature.

The short version is that every SaaS app that is trying to sell higher in the org chart starts building reporting functionality. Usually, this involves some engineering spending months getting model history saved in the right way, exposed to the API, pulling in charting and filtering JavaScript libraries, writing dastardly business logic around applying combinations of filters in an ORM. This is, eg, how my friend Andrew did it when building this feature for Zenefits in 2015.

Filesystem

In 2017 as an engineer at Plangrid (construction software SaaS), I spent about three months implementing a filesystem in our web app and backend. We needed a filesystem because we wanted to allow our users to sync their large external drives of project documents into Plangrid so that it was accessible to users on their iPads.

The filesystem itself worked…pretty much like you’d expect. It supported all the standard file/folder operations: create, move, delete, rename, list and involved a bit of complexity around storing a hierachical data structure in a relational database.

I’d describe a filesystem as a “medium-tail” feature. Not every SaaS app needs to support a nested filesystem.

But if I had to guess, I’d say there are probably in the low thousands of SaaS apps supporting this, plus countless internal tools in enterprises. These apps are one of the reasons Dropbox’s market cap flatlined — it was a product that became a feature!

If you squint you can see a startup: “open-source, embeddable Dropbox with your own control plane.” IPO-able? Definitely. (Maybe Kloudless missed the boat.)

(insert joke about rsync and the famous Dropbox HN comment)

The maturation of SaaS features

There are a couple truly universal SaaS features like auth, a few “popular” SaaS features like reports, and dozens of common features like a filesystem.

A product feature “becoming an open source library” as the third step in a process of “shifting rightward” on a product maturity axis like a Wardley map.

• First, Stewart Butterfield and team spend engineering man-years building Slack.
• Second, SaaS apps spend engineering man-months building features like chat and notifications into their apps. The best account of this is probably Kevin Kwok’s The Arc Of Collaboration.
• Third, the pieces of functionality represented get encapsulated into open-source libraries, making them buildable in engineering man-days or man-weeks

Ie, SaaS service => SaaS feature => open-source library/toolkit.

So — could we abstract out these features, in the most common backends (Python, Node) and for the most common use-cases? As open-source startups? Hopefully in the next few years?

Or restated: can we uplevel our primitives we use to build SaaS apps? From mostly using cloud-computing primitives (EC2, S3, etc) and development frameworks, to mostly using application primitives?

Common SaaS functionalities

Here’s a baker’s dozen set of common SaaS functionalities off the top of my head. You could probably come up with a bunch more. Most of these categories have $10B+ of market cap at play.

(*) Open-source but last generation of technology

Interesting questions

• If you’re an open source company doing this, do you eventually replicate the same feature set in every language? Every framework? (Django + Flask? Rails + Sinatra?) Or does the space fragment by language and by category?
• What DX patterns will emerge for UI customization with custom components, layouts, flows? How will these tools integrate with existing players? Eg, someone wants Mailchimp as your source of truth for onboarding emails to leverage their analytics and allow nontechnical editors)?
• Will there be a control plane(s) or data/provisioning layer(s) that abstracts across SaaS providers, similar to how Terraform abstracts across Cloud providers? Will this need to be designed separately by providers for each category or will it cross categories? Could it include inter-tool migration (like Segment for analytics), both expanding the reach of SaaS and commoditizing it?

PS we are already doing this in website world

Three years ago I wrote up a series on the Gatsby blog coining the term “content mesh”. Go read the whole thing if you want, but my point was that in the Jamstack and modern website world we are already doing the thing I’m describing — stringing together a bunch of application primitives like search, e-commerce, and auth to make this meta-application we call a website.

Yes, websites are in many ways simpler than SaaS applications, there is a lot less user-specific state and the POST operation set is more restricted. I get it. But if we can do it for a somewhat simpler application, it seems much more plausibly possible for complex ones?

Stay tuned for future evolution on my thoughts as this relates to the website space :)