SaaS in the Real World: Four Takeaways After 20 Years of Watching Vendors Come and Go

We have been buying, running, and occasionally replacing SaaS applications on behalf of customers since before anyone called it SaaS. When Logical Front started in 2003, the term of art was "ASP" — application service provider — and the vendors that survived mostly rebranded into what we now call SaaS. The marketing evolved. The underlying engineering problems did not.

This is not a "what is SaaS" article. This is what we actually tell customers after watching hundreds of SaaS adoptions from close range, in K-12, higher ed, healthcare, local government, and general business.

Takeaway One: The Cheap Monthly Fee Is Not the Total Cost

The first number in every SaaS pitch is the per-user monthly price. It is the least useful number in the entire conversation.

The real cost of a SaaS application is the sum of:

• Per-user subscription, usually tiered with the features you actually need only in the top tier
• Integration and middleware — connecting the SaaS to your identity provider, your data warehouse, your CRM, your ERP
• Data egress if you ever want your data back, either for migration or for analytics
• Custom development against the vendor's API, which you will need more of than you think
• Training and change management for staff who will not simply "figure it out"
• Admin time — SaaS does not eliminate admins, it changes what they do

A $12-per-user-per-month HR system quoted for 500 people is not $72,000 a year. By the time you factor in the Workday-or-equivalent connector, the SSO setup, the custom reports, and the one-FTE-equivalent of admin time, you are often north of $150,000 annually for the first two years. The vendor is not lying — the subscription really is $72K. They just did not mention the other $80K because it does not appear on their invoice.

When we scope SaaS adoption for a customer we build a three-year TCO that includes everything on that list. It almost never matches the procurement team's budget the first time around.

Takeaway Two: The Vendor Owns Your Roadmap Now

On-prem software made you responsible for upgrades. That was annoying but it meant you controlled when upgrades happened. SaaS inverts that tradeoff completely.

Your SaaS vendor will push features, retire features, change pricing tiers, and occasionally break integrations on their schedule, not yours. If you are running a K-12 student information system and the vendor decides to deprecate a grade export format the week before report cards go out, you are not going to win that argument by filing a ticket. You are going to scramble.

This is not hypothetical. We have watched vendors:

• Remove bulk-export features that customers relied on for reporting, citing "performance optimization"
• Raise prices 25 to 40 percent at renewal with 60 days notice because a private-equity firm bought them
• Change authentication flows in a way that broke a dozen customer integrations over a weekend
• Sunset an entire product line and migrate customers to a "successor" that was missing 30 percent of the features

The honest response is not "avoid SaaS." It is to assume your vendor will do one of these things eventually and plan accordingly. Keep a data-export routine running on a schedule. Document your integrations. Know your exit cost before you sign the contract, not after.

Takeaway Three: Integration Is Where the Money Goes

The first SaaS app in your environment is cheap. The tenth is not, because by then your real work is connecting them.

A typical mid-market customer we see has 40 to 80 SaaS applications in active use. Each one has its own identity story, its own data model, its own webhook payload, its own rate limits. Making them behave like a coherent system is a full-time job that nobody budgeted for.

We tell customers to plan the integration layer before they plan the SaaS portfolio. That means:

• A single identity plane. Entra ID, Okta, Google Workspace — pick one and require every SaaS vendor to federate with it. No local user accounts. SCIM provisioning where available.
• A central iPaaS or event bus. Workato, Tray, n8n, or a home-grown equivalent. Point-to-point integrations multiply quadratically and become unmaintainable around application number six.
• A data warehouse or lakehouse as the reporting truth. SaaS reporting is almost always worse than what you can build against a warehouse that has the joined data from every app.
• An API gateway or service mesh if you are exposing your own APIs to SaaS webhooks.

A customer with 60 SaaS apps and no integration strategy is in a worse position than a customer with 15 SaaS apps and a real one.

Takeaway Four: Not Every Workload Belongs in SaaS

The pendulum has swung so far toward SaaS that people have stopped asking whether a given workload should be there. Sometimes the answer is no.

Workloads we routinely recommend staying on-prem or in a private cloud, not SaaS:

• Large-scale file storage with predictable access patterns. SaaS object storage is priced for sporadic access. A research dataset that is read hot and read often is cheaper on a local NAS or a colo minio cluster, often by 5x to 10x.
• High-throughput transactional workloads. A customer doing 20,000 transactions per second against a database is not going to be well-served by a generic SaaS database tier. The per-transaction pricing breaks the math.
• Latency-sensitive workloads where the users and the data are in the same building. Round-tripping to a cloud region for a workflow that used to run on a LAN server is a regression, not a modernization.
• Regulated data with sovereignty requirements. Some SaaS vendors will sign a BAA and store data in US regions. Many will not. Know the answer before you procure.
• Applications that are genuinely bespoke to your operational model. If your workflow is your competitive advantage, do not move it to a SaaS product whose roadmap is dictated by what every other customer wants.

The pattern we recommend for most mid-market customers is hybrid. SaaS for commodity workloads — email, productivity, HR, expense, helpdesk. Private cloud or on-prem for workloads that are genuinely differentiated, regulated, or cost-sensitive. This is unfashionable in vendor marketing and almost always correct in practice.

What We Do Differently

When we architect a SaaS adoption for a customer we are explicit about four things up front: the full three-year TCO including integration and exit, the identity and data integration strategy, the workloads that should stay off SaaS, and the exit plan for when the vendor disappoints you. That last one gets written down, signed off on, and revisited at every annual renewal.

Twenty years in, the vendors we started with are mostly gone. The applications live on under different names, owned by different private equity firms, running in different data centers. The customers who planned for that reality are fine. The customers who did not had a harder decade than they needed to.