Prismatic leads in satisfaction for embedded iPaaS!

Prismatic
Blog
Why Dev Teams Are Incorporating SaaS Tools as App Components
Integration Product Strategy

Why Dev Teams Are Adding More SaaS Tools as Application Components

Dev teams are increasingly incorporating SaaS tools as components of their applications rather than developing every last bit of functionality from scratch.
Aug 11, 2020
Beth HarwoodChief of Staff

Most modern dev teams have little appetite for spending weeks or months building payment processing from scratch, when they can instead quickly incorporate a SaaS tool like Stripe to handle that functionality. There's a lot of upside to using a tool like Stripe: it cuts development time, abstracts much of the complexity associated with payment processing, and reduces maintenance effort. That's pretty darn appealing when you're racing to get your product to market and staring down a mile-long list of features to build.

The trend: incorporate rather than build in-house

It's not just payment processing, of course. A clear trend in modern software development is that dev teams are increasingly incorporating SaaS tools as components of their applications rather than developing every last bit of functionality from scratch. This is especially true for components that are:

  1. Complex and time-consuming to build in-house, and
  2. Not part of the product's core functionality

Auth0 recently shed some light on this trend with a survey of hundreds of software developers, engineering managers, architects, and CTOs. In their report The 2020 State of Application Assembly, they found that "rather than build everything in-house, the majority of app builders now utilize best-in-class SaaS APIs... to enable unique features and functionalities."

Payments, authentication, and messaging are common examples of application components that many dev teams choose to implement using a SaaS tool rather than build in-house. In fact, in the Auth0 survey cited above, 74% of respondents who needed to implement payments used a SaaS tool like Stripe rather than building that functionality themselves. For authentication, 58% chose to use a SaaS – or IDaaS, Identity as a Service – tool such as Auth0. For messaging, 71% chose to implement a SaaS tool such as Twilio.

The list of application components that dev teams are increasingly incorporating using a SaaS tool is large and growing. Just to name a few:

  1. Payments via tools like Stripe
  2. Authentication via tools like Auth0
  3. Messaging and communications via tools like Twilio
  4. Dashboards and ad hoc reports via tools like Zoho
  5. News feeds and activity streams via tools like Stream
  6. Application monitoring via tools like Datadog
  7. Real-time status communication via tools like Statuspage
  8. Integration building, deployment, and support via tools like Prismatic

We'll come back and explore that last one, integration platforms, in a bit.

Why dev teams leverage SaaS tools as application components

So why are modern dev teams leveraging SaaS tools to implement many application components rather than building all functionality from scratch? Let's examine some of the biggest benefits to this strategy.

  1. Get to market faster. When it's a race to beat competitors to launch your product or the next game-changing feature, speed is everything. It does take some upfront development time to incorporate a third-party tool into your product, but typically far less than building the same component from scratch.
  2. Leverage expertise and abstract implementation details. Many of the components for which dev teams incorporate third-party tools represent complex domains in their own right. Incorporating a SaaS tool lets you benefit from the provider's deep expertise in that domain rather than trying to learn a brand-new domain quickly and well enough to make all the right decisions about what to build and how to implement it.
  3. Provide more functionality. When you incorporate a third-party SaaS tool into your application, you get more functionality than what you would build in-house. A SaaS tool usually provides a rich set of features that you can easily pull in, either right away or later when the need arises. When you build a complex application component yourself, time and resource constraints mean you're likely to implement the bare minimum and cut everything that's non-essential.
  4. Decreased maintenance effort. When you leverage a SaaS tool for a part of your application functionality, maintenance and updates are included in the fees you pay to the SaaS provider. For example, at the time of this writing, Stripe claims to deploy their production API an average of 16 times a day to release new features and improvements and stay ahead of industry shifts. There's a huge ongoing efficiency win that comes with not having to maintain complex but non-core components of your product yourself.
  5. Reduced cost. No one likes to get another invoice every month. But dev time is expensive, and when you factor in reduced upfront dev time and decreased maintenance effort, the savings tends to far outweigh the cost of the SaaS tool.

A SaaS tool to consider incorporating: integration platforms

Given those benefits – and the increasing number of SaaS tools available for application components – we can expect this trend to continue.

As it does, one SaaS tool that teams should explore incorporating is an integration platform. Many dev teams, especially those who provide software for niche vertical B2B markets, spend an inordinate amount of time providing integrations between their application and the other systems their customers use. Building individual integrations from scratch is incredibly time-consuming, not to mention the time it takes to deploy them to customers, maintain infrastructure to run them, monitor and support them, and so on. Such teams may look to an integration platform – a comprehensive toolkit for building, deploying, and supporting integrations – to make integration work an easier, less manual, more repeatable process.

Not only are integration platforms highly beneficial, they are an excellent candidate for leveraging a SaaS tool. They resoundingly meet our criteria of being:

  1. Complex and time-consuming to build in-house, and
  2. Not part of the product's core functionality

Integration platforms: complex and time-consuming to build in-house

Integration platforms, sometimes known as iPaaS or Integration Platform as a Service, are a SaaS tool that reduces integration effort. A high-quality integration platform fitting for B2B software companies requires a complex set of functionality, including:

  • An integration designer that enables easily building reusable integrations.
  • Customer deployment management functionality that allows deploying integrations to multiple customers and handles customer-specific configuration and versioning.
  • First-class integration logging, monitoring, and alerting tools that enable better customer support for integrations.
  • A robust catalog of pre-built components ("integration building blocks") that handle most integration logic, as well as support for building your own components to handle product-specific, industry-specific, or otherwise non-standard integration requirements.
  • An embeddable, white-labeled customer portal that allows customers to access integration tools and documentation from directly within your product.
  • An embedded designer that enables your customers to build their own integrations between your product and other apps they use.
  • A purpose-built infrastructure and environment for running integrations.

That's a lot to build. Most teams can't carve out the time to build such an integration platform in-house or would need to omit many of these items due to time constraints.

Integration platforms: not part of core product functionality

Aside from not being able to take the time to build an integration platform in-house, most teams probably shouldn't because it's not their core competency.

An integration platform abstracts the many aspects of integration work that are not specific to your team's core product domain, including:

  • Integration coding work such as triggers, authorization, data formats, data protocols, data transformation, and connectors.
  • Integration infrastructure work such as production and dev environments, security, testing frameworks, logging and alerting tools, versioning, and deployment.
  • Tools and documentation for non-developer groups such as a documentation repository, logging/alerting access, an embeddable customer portal, and an integration marketplace.

With those items abstracted or greatly reduced in effort, software teams can focus on the aspects of integration work where their domain knowledge is critical, such as product vision, customer discovery, business logic, and customer training.

And of course, as happens when you incorporate any SaaS tool as a component of your platform, you also free up time to drive your core product forward – whether you're racing competitors to market or hustling to deliver that next big feature customers are clamoring for.

Share this post
Headshot of Beth Harwood
Beth HarwoodChief of Staff
Beth brings over 15 years of experience growing SaaS products and companies. She co-founded Prismatic in 2019 to help B2B SaaS companies unlock potential through better integrations and more time for core product innovation.
Get a demo

Ready to get started?

Get a demo to see how Prismatic can help you deliver integrations fast.