The Railsification of SaaS
I like to think a lot about the future of computing. Along with a small team I run a company called Autocode which launched in July, 2020. One of the opportunities we are focused on is what I refer to as the “Railsification of SaaS,” which I believe is going to be a major driver of both how software is developed and how it is purchased over the next decade. This article is an attempt to summarize some of my thoughts, and I think it’s important to understand a little bit about the the history of software development to paint a better picture of the future.
Every decade since the dawn of the World Wide Web in 1989 there has been at least one paradigm shift in how web software is built and delivered. In the 1990s we saw the mass industrialization of web development with PHP and Apache HTTP Server. In the 2000s, package management and frameworks made development even easier with RubyGems, Ruby on Rails, PyPI and Django. Then, in the 2010s, we saw the cloud take over: distributed and scalable computing became more accessible with the introduction of Docker and Kubernetes for orchestrating server environments and AWS Lambda for a promise of zero-ops, event-driven and on-demand computation.
I believe the one of the transitions we’re likely to see this decade borrows from things we’ve learned from the last three. Quite simply, the “Railsification of SaaS” refers to the inevitable conjugation of easy development, package management and cloud computing as applied specifically to the commercial SaaS ecosystem. It’s the standardization of the way SaaS products and their APIs interact with each other and the web programming environment as a whole.
The past: SaaSification of Rails
Before we get to the “Railsification of SaaS,” I think we should talk about the thing that’s already happened, which is the SaaSification of Rails. From late in the 2000s to the early 2010s a few aspiring entrepreneurs began to take note that while the Ruby on Rails ecosystem was superb, there were still things that were frighteningly complex to tackle as a developer. Building an online store was extremely difficult. Adding payments to your app required a relationship with a bank and running through a compliance checklist. Yikes. Adding SMS was nearly impossible.
Companies like Shopify borrowed concepts from the Ruby on Rails ecosystem to offer what is effectively a retail module for the internet. Click a button, create a store, start selling. Customize with code and templates. Though not often thought of in this context, Stripe and Twilio represent the first successful at-scale monetization of the RubyGems, PyPI and NPM ecosystems: “install this gem, pay us, we’ll do the hard stuff.”
All of the innovation unlocked by the Ruby on Rails ecosystem opened up an entirely new realm for commerce online. This SaaSification of Rails is a phenomenon that runs in parallel with the concept of the API economy, the overlap being that package management ecosystems are the primary distribution and integration point for APIs.
The future: Railsification of SaaS
In part due to the phenomenon of the SaaSification of Rails, third-party SaaS APIs are now ubiquitous. To build a full commercial offering or even a side project, builders often don’t just open up a development environment, download software, and start coding. A builder today may not start with code at all — maybe they begin an idea with structured data in Airtable. Maybe they start their own online business via Shopify. The ones that do start with code may find themselves quickly wanting to add payments with Stripe. And then they want to make sure their software can send messages to their communication channels — like Slack or Discord. Maybe they want to add authentication to their app easily with Auth0.
While the SaaSification of Rails refers to something that’s already happened — the commercialization of software packages at scale — the Railsification of SaaS refers to what’s next: re-integrating and simplifying the increasing complexity of the SaaS landscape into standard, simple and shareable components and packages. While I can’t possibly enumerate all of the implications of this movement, I can begin to list a few that are already in progressing in parallel with it.
First, the definition of “software developer” is changing, plugging together SaaS apps is becoming a viable — and sought-after — job. PHP developers of the 90s without degrees were sometimes scoffed at; many of those folks are multi-millionaires today. The same thing will happen between the 20s and 30s with tools that emerge this decade.
Second, the viable surface area for innovation in application development is increasing exponentially. Investors in Silicon Valley are calling this the “no-code” or “low-code” movement, but it will invariably converge towards code as the most functionally reproducible and testable medium. You can’t share a Zapier integration universally. You can, however, copy and paste a few lines of JavaScript, Ruby or Python and run it anywhere. There’s not likely to be just one company, framework or new piece of software that wins this decade. There will be a dozen or more.
Third, there is an opportunity to build the RubyGems of SaaS APIs. Anybody who has spent time with APIs outside of Stripe and Twilio has realized that SaaS integrations are mostly godawful. There are existing standards for machine-readable API specifications — OpenAPI, for one — but they are only a fraction of the story and not even well-adhered to. Discord’s API is built around stateful socket connections, while Slack is now mostly a stateless HTTP API. Stripe mostly adheres to a specification congruent with OpenAPI, Shopify is a combination of nonstandard REST and a GraphQL API on top. Authenticating into any of these ecosystems is wildly different.
I mentioned previously that the “Railsification of SaaS” is something we think a lot about at Autocode. Specifically, building the “RubyGems of SaaS APIs,” is extremely interesting to us: our mission is to make people more productive with code. We’re doing this by making the web more programmable.
The summary is that Autocode is built to make it easy to ship code that connects SaaS apps together. We’re a small team of four that has built a web-based IDE, runtime, collaboration and hosting platform for web applications that’s stateless, auto-scaling, and always-on. We have a standard library of APIs to easily manage third-party API dependencies. We even automatically set up webhooks for you when you save your project. We have a CLI and local development tools for anybody that doesn’t want to use our browser-based IDE. Right now we only support building and adding to Autocode’s standard library with Node.js, but more languages are planned in the future.
Some people call Autocode a “low-code” tool, but the reality is that we’re all-code. We just make auth and API management a breeze as you build your apps. We’re extremely fortunate to be supported by Slack, Stripe and the CEOs of GitHub, New Relic, Airtable and Shopify.
What other opportunities are there?
The “Railsification of SaaS” is only one shift I think we’re likely to see this decade, there are a lot of companies innovating in the future of computing. I think it’s important to call out some of the ones that are succeeding in the front-end and distributed computing space.
On one hand, companies like Retool are leading the charge on front-end application development by providing better management and abstraction of components for visual development. As a developer, it reminds me of a more business-focused and tactile version of Ionic Framework. Retool is leaning on innovation from the past decade — namely, the React ecosystem — to build a more efficient, streamlined approach to visual tool development on the web.
On the other, there are companies like Repl.it that are leveraging distributed computing technology developed in the 2010s to enable anybody to ship any sort of software they want. While optimized towards educators and students, the team has grand ambitions — and rightfully so, they are empowering an entire generation of young developers to run any sort of server they want having to worry about how to set up Python or manage binaries. They even support BrainF***.
These are two of the faster growing companies thinking about the future of development. But they represent the tip of the iceberg. This whole decade of developer tools is going to introduce an entirely new canvas for software development; at Autocode we like to think about the web itself as a programmable interface. We’d be honored to find our spot among these emerging companies, but as a builder and developer you should think about the tools you can deliver as well. The more innovation the better.
There’s a lot to build. Looking forward to working on it with you.
Keith Horwood is a guy who spends a lot of his time building software. He’s the CEO of Autocode. He’s seen Avengers: Endgame like 20 times and plays Halo when he’s not writing code. You can follow him on Twitter if that’s your thing.
