“We are in the early stages of a huge shift away from building SaaS product capabilities in-house”

JAXenter: What are some of the big changes that you have seen over the past few years in how SaaS is being built?

Sagi Rodin: In recent years we have seen SaaS companies move towards integrating third party, full end-to-end capabilities, into their products. In the past, SaaS companies were hesitant to use externally developed product capabilities in customer-facing parts of their applications — with the notable exception of Stripe or similar solutions for payments. They were happy to use third party infrastructure solutions or open source UI component libraries. But when it came to a full product capability with customer facing parts, they inevitably opted to develop it in-house.

JAXenter: Why were the decision makers in SaaS companies hesitant to incorporate externally built product capabilities?

Sagi Rodin: I think that a lot of this comes down to inertia; a kind of chicken and egg problem. Companies didn’t consider third party solutions an option, so as a result, great third party solutions weren’t developed, so there were no good solutions for companies to consider — it was a never-ending cycle. There was a status quo where the default was to develop customer-facing SaaS capabilities in-house. Decision makers were stuck in this mindset and rejected suggestions to incorporate externally built capabilities. The common outlook was: “why pay for something we can do ourselves?” or “That’s what we hired all these developers for.”

Plus, there were additional barriers to overcome as well. There was a fear of the security implications of shipping third party code to customers, and the difficulty in integration being caused by the chaotic nature of the web development ecosystem — which suffers from a lack of standardization. These barriers prevented things from becoming unstuck, and even as SaaS companies began to look to third party solutions for things such as marketing sites, infrastructure, and internal project management tools, the adoption of these solutions lagged behind for in-app, customer facing capabilities.

SEE ALSO: DevOps and metrics – what should you be tracking?

JAXenter: What do you see as the key things that changed?

Sagi Rodin: Stripe actually played an important role in breaking this cycle. They tackled payments, which is a capability so complex, no company would consider building it on their own. Stripe capitalized on the move towards self-service SaaS and the demand for in-app payment solutions that came as a result and helped accelerate the move to self-service by providing a payments solution that was orders of magnitude simpler to integrate than previous options. Stripe made the brilliant decision to not just supply an API for payments but to offer an end-to-end solution — that includes customer facing payment flows — with just a few lines of code. The simplicity of their solution, combined with the complexity of implementing payments made them the obvious answer for many SaaS companies attempting to keep up with the growing demand for in-app payments driven by the movement towards self-service and Product-led growth.

Following Stripe’s lead, a number of other companies started offering full end-to-end product capabilities, including user facing parts, with very simple integration. The status quo has shifted and it’s now common for products to have a number of third party user-facing integrations, for not only payments, but also login flows and user onboarding, among others.

JAXenter: What about the security implications of including third-party code in the application that you’re shipping?

Sagi Rodin: Interestingly enough, security has actually shifted from originally being one of the main concerns, to today serving as a major benefit. Security is now seen as a constantly escalating arms race, with the attacks becoming more and more sophisticated with time. It is increasingly difficult for developers to stay at the cutting edge of the latest security measures and best practices. This is especially true when it comes to features with significant security aspects — features like Authentication, User Management, Roles and Permissions and API Keys. Today, developing these features in-house can become a liability. This is because properly implementing these capabilities is so complex and has so many nuances, it requires the knowledge of a security expert — something not every development team has. So, if instead you can integrate externally developed capabilities, after confirming that the supplier has the relevant security credentials (and takes it seriously), you can sleep easier at night knowing top experts who live and breathe security are keeping your customers safe.

But security alone is not enough. The most recent trend is that security is no longer just an infrastructure challenge. Within the product-led growth (PLG) movement, end-users would like to control the security narrative of their workspaces within any product they are utilizing. As a result, SaaS companies need to provide full self-served control of any security policy setting to their customers, within their products. This is what we call “inversion of control” of next-generation security within applications. Just imagine that an end user wants to configure their Active Directory within a SaaS app and in order to do so they need to open a ticket, talk to support, exchange metadata configuration files, and validate that it works while talking to a Customer Success rep over the phone. It just doesn’t work like this anymore. Customers want independence and full control over their workspace policies, MFA enforcement, SSO setup, granular and custom roles and permissions and much more.

This means that it’s no longer enough to just provide strong security infrastructure as a service, but you have to also provide it embeddable to your customer’s user interfaces. This of course greatly increases the complexity of implementing these capabilities. For example, a customer of ours needed to add SSO to their SaaS product and make it fully configurable and self-served for their end users. Their R&D team’s best estimate on the development effort was 7 to 8 months, but they had deals in the pipeline that were dependent on this. By integrating Frontegg’s SSO solution they were able to turn this around in a matter of weeks and close deals that would otherwise have been lost.

JAXenter: What has changed on the integration front?

Sagi Rodin: Although the web development ecosystem is still a bit messy, integration of third-party capabilities has become much more natural with the move away from monolithic apps towards microservices and micro-frontends. At the same time there has been a convergence on a small number of frontend libraries and frameworks, like Angular, React and Vue.js. These are all designed to be component-based and composable, which really lends itself to creating easy to integrate APIs. It has also opened the door for third party capabilities that have a large number of integration points and need to be finely woven into the application code, as opposed to solutions like Stripe that have a relatively small surface area for integration.

JAXenter: Where are things heading in the future?

Sagi Rodin: I think we are in the early stages of a huge shift away from building SaaS product capabilities in-house by default. Instead, we’ll look first for existing plug-and-play solutions and only develop in-house if we reach the conclusion that there’s nothing suitable out there. The result will be that most products will have significant portions that are third party integrations, while some products will be almost entirely composed from plug-and-play capabilities. Developing product capabilities from scratch will be reserved for cases when the capability is truly unique, innovative and core to the product.

We are already seeing the adoption of these kinds of solutions for in-app analytics (for example Looker), data onboarding (FlatFile) and search (Algolia). This is just the beginning though, and we will see this process accelerate over the coming years.

As customers will demand more independence and control over various aspects within their workspaces, SaaS vendors will have to deliver. Leveraging third party product capabilities as a service provides an efficient manner to do so.

But in order for these capabilities to become widely used two things need to be tackled. Firstly, they need to provide an amazing developer experience. This goes beyond just a clean, intuitive API. It requires clear, up-to-date and comprehensive documentation, and great support for developers generally, putting them front and center.

Secondly, they need to offer a great user experience. SaaS companies cannot — and should not — compromise on user experience. The user is king and even “security features” like login need to be designed with a seamless experience for the user in mind.

SEE ALSO: Automating the Right Processes: Task Capture vs. Process Mining?

JAXenter: What are the benefits of leveraging third-party capabilities? What is wrong with the logic of “why pay for something we can do ourselves”?

Sagi Rodin: I think the major flaw in this kind of thinking is a failure to properly account for the total cost of ownership (TCO). When you think about the cost of developing a product capability, the initial development costs are only the beginning. There are continual maintenance costs that arise from fixing bugs, adapting to changing product specifications and adding new capabilities.

Not to mention that the code for any given feature has a kind of half-life — some period of time after which the code will become legacy code and will need to be entirely rewritten. This is because the tech is constantly evolving — frameworks, libraries and best practices are always changing — and because shortcuts or assumptions that were made in the initial development may not hold up over time. The stubborn reality is that at some point you’ll ask an engineer to make a small fix or change to a feature that was hacked together years ago over the course of a few weeks, and they’ll come back saying that they can’t keep on putting patches on patches and they need to do a full rewrite. When integrating a third-party capability, the maintenance is done by the third-party behind the scenes.

Another consideration is the opportunity cost. We don’t have limitless resources and when you build a generic and non-differentiating capability yourself you are forgoing on building another capability that could make your product stand out from the competitors.

Finally there’s focus. Startups rise and fall based on how successful they are at remaining laser focused on their core mission. Offloading generic development work by using pre-existing solutions allows the development team to stay fully focused on the core product that makes your offering stand out.

Especially when it comes to capabilities for self-service and Product led-growth, there’s a tremendous opportunity to integrate ready made solutions. This enables teams to go to market fast with a fully mature product that can scale up quickly, without needing to sacrifice on the core product capabilities or on the self-service features that drive growth.

The post “We are in the early stages of a huge shift away from building SaaS product capabilities in-house” appeared first on JAXenter.