SaaS application providers are often at the forefront of technology adoption, building out highly-available, API-driven, multi-cloud applications. These providers are cloud-native, cloud-first, cloud-driven — and yet, unless they're AWS, Azure, or Google Cloud offering a direct connection to a business customer, application delivery is largely beyond their direct control. There is no SaaS application independent of the Internet and a range of external dependencies that are needed to provide a good user experience.

When building out new services, SaaS providers need to keep in mind a set of best practices and "habits of success," which cover their organization's culture, relationships with third-party providers and customers, and overall strategic decisions and operational know-how.

If you're a SaaS application provider, here are five considerations you need to keep in mind:

1. Stop Accepting the Culture of "It's Always the Network"

When it comes to troubleshooting user performance issues in your own environment, the network is usually the first target. The network team usually has to prove its innocence before the application team will mobilize. This default "blame the network" approach is not only a productivity-sucking distraction, but it can also inhibit team collaboration, which is critical to quickly identifying and resolving issues.

"Is it the network or the application?" is a frequent question in the war rooms of digital operations. Getting a quick view of network health (with application context) can enable you to demolish the flamethrowing network and application silos that have historically plagued traditional IT shops.

2. Reframe Your Relationship with Third-Party Dependencies

Most service providers don't have the resources to fully investigate or even acknowledge every performance-related inquiry they get each day, which can make resolving issues with them very challenging, particularly if you have no concrete data showing they're at fault. As a result, you can easily fall into a tiring routine where you try to escalate issues and your service provider swings into the 3 Ds: deny, deflect and defer.

You may infer responsibility based on tell-tale patterns or past experience, but most providers won't spend time troubleshooting on your behalf, particularly when they may be on the hook for a fix, or on the receiving end of a SLA penalty. This is where evidence comes in. When you live in the cloud, your troubleshooting mantra can no longer be just "find and fix," it must also be "evidence and escalate," where you have a proven set of steps to gather evidence (even across networks and services you don't control) that can get you to a successful escalation.

When you've mastered "evidence and escalation," you're no longer at the mercy of external providers (both direct and indirect).

3. When it Comes to Your Customers, Show, Don't Tell

As a SaaS provider, it's your job to perform "sleight of hand" and produce "SaaS magic" — a unified experience that results when every application component (many third-party), and every external network and service work seamlessly to construct and deliver your application. But when something does go wrong, you need to be able to quickly attribute responsibility to the right component of user experience — not only so you can work to resolve the issue, but also you can communicate appropriately with your users.

Today's end users demand transparency from their providers. Even if you're certain your application is not at fault, it's not enough to simply blame the Internet or some other external service. You need to be prepared to demonstrate the source of the issue (even if that issue is external) and provide some plan or guidance to improve the customer's experience.

In particular, when you're dealing with an enterprise customer's IT team, you will need to provide more details than "It's not us." Having a clear, step-by-step view of the application delivery path from your customers all the way to your application servers is critical to understanding where and why something's gone wrong and providing provable insight to your customers accordingly.

4. Monitor Interservice Communication that Spans External Networks and Services

Monitoring performance to your front door is an obvious way to monitor your user experience. But what about your application backend? Performance issues within your application stack can have a follow-on effect on user experience.

You may have RUM-based application performance management (APM) tools that use code injection to monitor user interactions with your app, but many of your application components rely on external APIs — like payment gateways, voice and messaging, CRM database, etc.— and any one of those can impact your application and, subsequently, user experience. Anytime you leverage an external API, it becomes part of your application stack and must be managed appropriately. You may not be able to monitor them using the same tools you do for infrastructure that you own, but you should still know when and why your APIs are available and performing or not, so you can get to root cause faster, reduce MTTR, and ensure that they're not negatively impacting user experience.

5. Embrace a Continuous Lifecycle Approach to Monitoring

It's easy to treat monitoring solely as an operations practice, where it's used to ensure service uptime. But having data early in your application journey can be key to making better choices around network and application architecture. For example, the choice of where to build your data centers or where to locate your workloads in public cloud providers can dramatically impact your service delivery.

You'll want to know how these choices will impact your application and users — before you deploy. Having detailed, visual, and reportable data that charts every aspect of user experience from web server, to network path, to Internet routing, before you roll out or scale out a new service can de-risk your most important SaaS planning decisions.

What all of these best practices have in common is end-to-end visibility — performance transparency across every provider and every service, not just your own. If you're able to "see every network" and related service like it's your own, you can radically re-frame how you function internally, how you service your customers, how you manage providers, and how you build a bulletproof performance play over time.