I recently read The SaaS Playbook by RobWalling (published by Amazon, https://saasplaybook.com/), an excellent and highly recommended read for any CEO and Product leader considering or planning a SaaS-delivered business. Unlike many business help books, it is short, easy to read and not padded out with pointless theoretical examples. It covers well the commercial dos and don'ts and how to bootstrap (without venture backing). However, it does not cover the 'how to build' or 'how to engineer', my primary interest in SaaS companies; hence, I thought it worth adding an engineering perspective.

According to a report by Grand View Research, the global SaaS market is expected to grow at a compound annual growth rate (CAGR) of just under 12% from 2021 to 2028, from a foundation of 158 billion USD in 2020. With the maturity of internet delivery, web and mobile technology, and cloud services scalability, the SaaS delivery model has now established itself as more than just a way to deliver product-based services; it is now the defacto way. It is a long time since I have heard anyone asking for software installation requirments or a product company suggesting minimum server sizings.

A question often asked when I talk at conferences or on speaker panels is: "What is special about engineering for a SaaS business?". There are the usual requirements for greater scalability, security, and high availability, especially with a multi-tenancy and essential business product. However, I want to cover three essential engineering requirements that are often overlooked and have a huge impact if not addressed. Multi-tenancy, where a single instance of the software serves multiple customers, is ofter regarded as the ony cost-effective approach, but it is not. Designing and building a non, or hybrid, multi-tenancy product is feasible and cost-effective, if designed with this in mind from the start.

(Note to self: the dos and don'ts of multi-tenancy, and how to build and stay cost-effective, is worthy of a follow-on article).

So, in addition to tenancy management, security, high availability and scale, these are my often-overlooked three engineering essentials.

Release, what release?

Unlike consumer websites, SaaS products are often essential and critical services for business customers. The service becomes tightly integrated with customers' vital business processes. This is good for the SaaS company, its commercial model and establishing that desirable, protective 'moat'.  As Warren Buffet famously said: “A good business is like a strong castle with a deep moat around it. I want sharks in the moat to keep away those who would encroach on the castle.”).

New releases, especially with functional changes, can not only significantly impact a customer's business, but the downtime for them can also have a significant impact. The Terms of Service may allow for planned/scheduled downtime, but trust me, customers always see it as an outage, an inconvenience and even sometimes a failure.

Designing and engineering for zero release downtime (yes, it is possible) or minimum downtime is vital. This is both about architecting and developing for zero/minimal release downtime from the start and having the discipline and process that enables you to commit to customers. If you are essential to customers, there can be no "sorry, we took longer than we need", "sorry we had to roll-back and will do it again in a few days", and my most hated (as a customer) "sorry, we did not inform you, but we are still within our Terms of Service". If your SaaS product is essential to a customer, the customer will need to plan and schedule just as much as you do.

(Note: With the rise of CI/CD, there are lots of excellent articles and books on understanding more about various strategies for zero or minimum impact release. In particular, I highly recommend Continuous Integration and Continuous Delivery: A Practical Guide to Designing and Developing Pipelines by Henry van Merode (https://www.linkedin.com/in/henry-merode-van-a676a93/))

Roadmap commitments are everything

Building a roadmap with customers can always be tricky. There are the common issues of customers having varying requirements and different priorities, which can be especially tricky when some are dominating whales, and others are minnows. In addition, there is also a challenge when a customer's ideas conflict with what you need and want to build, taking you outside your focus for the service as a whole. However, unlike typical B2C websites, customers will plan ahead and have high expectations, sometimes even commercial dependencies, on delivered roadmap features.

Expectations are just naturally set, regardless of how many caveats you put at the bottom of your presentation, for that road map to be delivered - exactly how they want it and when they want it. Faltering on your roadmap is commonly the first seed of distrust for customers; if they can't trust you to deliver the roadmap, how can they trust you to provide an essential service to their business? SaaS product roadmaps are more than just roadmaps, they are a commitment. Contrary to many more straightforward product businesses, SaaS product companies have to be highly disciplined, with solid processes and delivery structures.

No multiple versions here

For a long time and good reason, there has been a mantra in the SaaS world: "Feature-toggle, not version". In the SaaS world, technical debt is not just old code, it is multiple versioning. Multiple versions happen because there are always customers who want something unique, a feature just for their own business or because they can't support the new version (they are too hard-wired in). Other than a temporary measure to assist a phased roll-out, any multiple versioning will just be more damaging technical debt; simply don't go down that road. The architectural and software design philosophy, should always be a feature toggle, never a version. Multiple versions simply exponentially increase the implementation effort, risk, and testing required. As with all technical debt, the situation will quickly increase the effort and time needed to deliver your roadmap, waste your money and demoralise your team.

---

If the intricate demands of security, multi-tenancy, high availability, single-versioning, unalterable roadmaps, and rigorous release prerequisites make you hesitant to adopt a SaaS solution for your product, don't be put off. These challenges become manageable with adequate pre-planning, mindful engineering, and a realistic attitude. Compared to a standard product distribution strategy, the business advantages of a SaaS delivery model are well-examined and established, making SaaS a worthwhile pursuit for most commercial situations. As usual with all tech implementations, a little strategic wisdom and deliberation always pays dividends later on.

As my friend, a CTO at a well-established SaaS business, once told me over a reflective beer,  "I thought bringing up three kids demanded boundaries, structure and planning, but it's a breeze compared to this".