The SaaS Hangover Is Real... Here's What Comes Next
Lately, I've started to see more and more evidence that businesses are entering something of a "SaaS Hangover". In 2025 alone, 83% of companies reported experiencing a cloud data breach, and 70% of businesses using SaaS apps have lost data from those apps (msp360). High-profile supply chain attacks have shown that even "safe" SaaS vendors can become attack vectors. Meanwhile, as geopolitical volatility increases and the tech regulatory environment continues to become more stringent, businesses are starting to reconsider who should own their data.
This, along with the maturation of cloud service offerings, has led to the growth of a new form of software delivery, Bring Your Own Cloud (or BYOC). In this method, a customer grants a vendor access to a sandboxed cloud environment. The vendor then deploys and manages their software on behalf of the customer. This allows customers to maintain control over their data while still being able to take advantage of a managed 3rd party service.
This article will provide more context around BYOC and the tradeoffs between it and other more mature forms of software delivery.
A brief history of software delivery
Before we dive into the nitty gritty of BYOC, I think it's important to provide a bit of background on how enterprise software is shipped to customers. This should help shape the landscape of software delivery so that you can better understand the unique value proposition that BYOC brings to the table.
Self-Hosted
Self-hosted (or on-prem) is arguably the oldest form of software delivery, dating to pre-historic (well, just pre-Internet actually) times. It's a very simple model; a vendor delivers an artifact to the customer, and the customer runs it. This artifact could be anything... a binary, zip archive, VM image, CD, or even a floppy disk.
In this model, the customer is responsible for deploying and operating the vendor's software (possibly augmented by highly paid consultants). The vendor has little-to-no control over the software's actual execution environment, as it's controlled exclusively by the customer.
So when anything goes wrong at any point during the installation, maintenance, or upgrade process, the customer must reach out to the vendor for support. Customer support is no easy feat, and can be tedious for both sides. Even more so when customers operate in locked-down corporate environments or regulated industries.
From the customer side, incidents can involve confusing ticketing systems, multi-channel back-and-forth communication across timezones, unhelpful documentation, or a slow response time from the vendor. But it's not all rosy for vendors either, as they could be dealing with problems like incomplete information, inability to debug, and unfamiliar runtime environments.
Why go through all this trouble? Well, one significant benefit of a self-hosted deployment model is that the customer has full control over their data. They can install the vendor's software in their own datacenter, on their own encrypted disks, and behind a strict firewall. For many highly regulated industries, this is a non-negotiable.
But starting in the late 1990s as more consumers started connecting to the Internet, another business model started to gain tremendous popularity...
SaaS (Software as a Service)
In a SaaS application, the software vendor controls all aspects of the deployment by deploying software on their own servers. Customers are granted access to the software via the public Internet. This is how most B2B and B2C software runs today.
As a software vendor, there are several operational benefits to running a service on your own infrastructure. Your DevOps team can easily set up in-depth observability pipelines to analyze every detail of the service. Software can be upgraded as quickly as you can run your CI/CD pipelines. A/B testing can be implemented across the userbase to improve the product at a lightning-fast pace.
Not only are there operational benefits to SaaS, but finance departments and investors highly value businesses that operate SaaS products. SaaS vendors can effectively expense a server's cost across multiple customers, reducing the marginal cost of adding new users to basically nothing (outside of customer acquisition costs). This has led to tremendous sales growth and valuation multiple expansion over the past 20 years.
Massive billion dollar companies have been built on this model. The pantheon of Unicorns and Wall Street darlings is full of SaaS vendors. SaaS is even recognized as its own distinct category in stock market indices. It has lowered the bar for users to access highly scalable and complex services by only requiring an email address and maybe a credit card to sign up. This reduces the onboarding time from months (in self-hosted deployments) to minutes, maybe even seconds!
However, it's not all sunshine and roses in SaaS-land. One major drawback is that the vendor owns the customer's data. Everything that happens once data enters a SaaS application is opaque to the user. The customer is at the mercy of the vendor's security and compliance teams, and can only hope that their sensitive data is managed with care and doesn't end up in a leaked database somewhere on the dark web.
Furthermore, since they are the custodians of customer data, SaaS vendors have significant pricing power over their users. A vendor can make it difficult or expensive for customers to export data out of their system, adding to the cost of moving to a competitor. Because of this power, vendors can charge excess fees to maintain or expand the service. This leads to future pricing uncertainty for the customer. The lock-in is real!
Finally, there is an operational risk of an outage, or a company simply going out of business. If a SaaS provider experiences an infrastructure problem, the customer can't do much except for pray that service is restored in a reasonable amount of time. Even worse, if a vendor runs out of money, or simply decides that their SaaS product is no longer worth the effort of maintaining it, customers are left scrambling looking for a replacement.
There has to be a better way to have more control over your own organization's data while avoiding the headaches that come with a self-hosted solution...
Enter Bring Your Own Cloud
Bring Your Own Cloud (BYOC) is a software delivery method that bridges the gap between self-hosted and SaaS. In a BYOC deployment, the vendor deploys their application inside of a customer-owned cloud account. All major cloud providers have features that allow for secure management delegation to a third party; this is a common workflow for consulting firms and MSPs. Using these tools, a vendor can manage their own software in an environment that the customer owns. This unlocks a unique set of properties which make BYOC attractive to modern customers.
BYOC can help bridge the gap for customers who want control of their data, but may not have the in-house expertise or desire to manage large-scale software platforms.
Here's a table that highlights the key differences between self-hosted, SaaS, and BYOC:
| Self-Hosted | BYOC | SaaS | |
| Who manages infrastructure? | Customer | Vendor | Vendor |
| Who owns the data? | Customer | Customer | Vendor |
| Who pays for the infrastructure? | Customer | Customer | Vendor |
| Is the service public? | No | No | Yes |
| Initial time to launch | Months/Weeks | Weeks/Days | Minutes/Seconds |
As in SaaS, a BYOC vendor manages the software runtime environment. However, in BYOC, the customer is the one who owns the infrastructure, not the vendor. Because of this, the customer gains root control over their own data. This includes the ability to run a service completely behind a corporate firewall.
Data Ownership and Enhanced Security
In a BYOC deployment, the customer retains ownership of their own data, since they are the owner of the account and can revoke access to the vendor at any time. The vendor can use private networking to keep all traffic to-and-from the service out of the public sphere, further improving the service's security posture.
Fewer operational woes
BYOC allows vendors to manage customer deployments in the same way that they would manage their own multi-account applications. Since the vendor has audited IAM access to a customer's account, they can use all of the latest and greatest cloud automation and tooling to manage their software.
Because of the required coordination between the customer and vendor, onboarding onto a BYOC product can take longer than signing up for a SaaS service. This is especially true for services that run on cloud private networking, since the customer needs to integrate the new application into their existing network topology. Luckily, cloud providers have provided golden path solutions for cross-account and cross-network connectivity that, combined with some clever IaC, can automate most of the pain out of the initial deployment. And this type of deep integration is not even possible with a SaaS product.
Improved support
In a typical BYOC application, the vendor deploys an observability solution to monitor their software. With these pipes flowing, there is no longer a need to ask the customer to dig up logs on a support call. And vendors can even take proactive steps to correct potential errors based on live metrics. By adding alerting into the mix, vendors can manage software running in customer accounts the same way that they would manage it on their own infrastructure. A customer incident would look no different than an internal one and should be no harder to fix.
Highly sensitive customers may require an air-gapped deployment, blocking all network egress to vendor telemetry servers. While this prevents proactive support measures, vendors can still make it easy for customers to export a package of debug information when problems arise. And since the software is running on infrastructure standardized by the vendor, reproducing bugs should be just a little easier.
How much will this cost me?
Since the customer is using their own cloud account to run the vendor's software, the customer pays for all of the service's infrastructure costs. While this usually leads to a higher TCO (Total Cost of Ownership) than it would for the equivalent SaaS service, customers are effectively paying a premium to own their data. And some properties of BYOC can offset these higher prices:
- The vendor's support burden for BYOC is significantly less than for a self-hosted product. Supporting self-hosted software at-scale across a variety of heterogeneous infrastructure is a costly activity, and can require significant resources that many smaller companies and startups simply don't have. This can lead to price reductions as compared to traditional enterprise licenses.
- Customers have the option of using cloud credits to cover BYOC infrastructure costs. All of the major cloud providers have various programs for startups and incubating companies to get potentially hundreds of thousands of dollars in free usage credits. By deploying vendor software into their own accounts, customers can utilize those credits to reduce the TCO of the service.
- BYOC even makes it easier for the vendor to unlock these credits. Instead of jumping through hoops to launch a SaaS product on a cloud marketplace to enable customers to pay via cloud credits, by directly managing infrastructure, BYOC enables vendors to quickly deploy their product and allow customers to use credits.
Just as BYOC sits between SaaS and on-prem on the delivery spectrum, it tends to sit there on the cost spectrum as well.
The future of BYOC
There is no best deployment model. Each has its own set of unique properties, and it's up to the consumer to pick the product that's right for them. BYOC deployments can be a great fit for customers who value data ownership but want to delegate software management to the experts. But if you're under tight time or budget constraints, a SaaS product may be a better fit.
I see BYOC gaining traction as companies continue to migrate business-critical workflows to the cloud. Security and data residency concerns are paramount in major industries like finance, healthcare, and defense. BYOC helps companies in these industries leverage the raw power of cloud compute in a secure manner without the headaches of managing these resources themselves. BYOC can also appeal to startups that are flush with promotional cloud credits and don't have the personnel available to monitor critical services 24/7.
BYOC isn't for everyone, but for the right customers, it's a game-changer.