I recently got in a discussion on the Slack associated with the Hacking SaaS substack. (Which if you’re in the industry, you should definitely read!) The question was about what kinds of tools you should feel comfortable using if you’re an engineer at a SaaS business. The conversation then turned to the nature of: what exactly is it you’re trying to accomplish with a SaaS business?
I really think the “S stands for Service” part of SaaS needs to be more prevalent.
My former job was as CTO at a biotech; the tech dept built a complex software platform which was entirely inward-facing. But I still thought of our mission as SaaS. The total nature of SaaS doesn’t apply in-house since you don’t “sell” your software, but most aspects of it were still relevant. As I explained to our CEO there at one point:
SaaS is “Software as a Service”. That boils down to 5 things:
- [Distribution] You don’t install the software from a CD on your own computer, it’s delivered to you online.
- [Maintenance] You don’t have separate sysadmins who maintain your installation; devops/SRE integrated with the SW engineering team that authored it keeps it running.
- [Product mgmt strategy] As a result of [1] and [2], you don’t have “big bang” releases; there is no “FooSoft 2.0 release”, you just keep rolling out changes over time. For “boxed” software you need to suck less with every release; in SaaS the goal is “suck less, every day/week/sprint.”
- [Sales model] Pay-as-you-go on some value- or capacity-driven model rather than “buy once upfront.” (This one was not relevant for in-house software.)
- [Mindset] We are here to create value for users and help them accomplish their goals. It’s not about getting the thing out the door and selling copies, it’s about keeping a set of users engaged and finding continuous value so they want to keep using it. (Which ties to [3])
So to the question of “what tools ought a software engineer feel comfortable reaching toward,” I think you use what you need to use so that you can “do what it takes to make them happy.”
I work in commercial enterprise SaaS now; we charge a lot for our service and customers expect a lot of value. They let us know it in the form of complex “customer enablement” support tickets they file (requesting data backfills, or customizations, or special-case exports for various reasons, and so on) which are often escalated to engineering. And especially in those cases, you don’t have to write a “weapons grade” bulletproof API to do the job, it just needs to get done; choosing the right tool for the job to dispatch it expediently is, I think, what good engineering is all about.