At a certain scale, every successful SaaS company has to answer a quiet but important question: are customers staying because the product keeps getting better, or because leaving has become too painful? Ideally, those two things would never be in conflict. A great product naturally becomes embedded in the way a company works. It becomes part of the operating system of the business. People build processes around it, train teams on it, integrate it with other systems, and rely on it to make decisions. That kind of dependency is not inherently bad. In fact, it is usually a sign that the product is working. But there is a point where dependency can become the product itself, and that is where the relationship between vendor and customer starts to change.

👉🏼
Are customers staying because the product keeps getting better, or because leaving has become too painful

The healthiest SaaS companies build moats out of quality, usefulness, flexibility, reliability, and trust. They make it easy for customers to choose them again because the product keeps earning its place. The less healthy version builds a moat out of switching costs. It asks customers to invest in proprietary workflows, proprietary languages, specialized skills, complicated integrations, custom data models, and organizational habits that make the product harder and harder to leave. From the outside, both strategies can look like growth. Revenue expands. Customers renew. The product footprint gets larger. But from the inside, they feel very different. One feels like momentum. The other feels like captivity.

The tricky part is that switching costs are not always malicious. They often begin as a byproduct of real value. A platform gets more powerful, so customers build more inside it. The vendor adds custom configuration, workflow engines, scripting tools, extensibility models, marketplaces, admin features, and integration layers because customers need more than a simple tool. Over time, the product becomes less of an application and more of an environment.

👉🏼
Over time, the product becomes less of an application and more of an environment

That can be incredibly useful. The danger comes when the company realizes that the environment itself is the moat, and that making the system more portable, more standards-based, or easier to leave might reduce its leverage. At that point, the incentives can quietly shift. The company may still talk about customer value, but the product strategy starts to favor capture over usefulness.

Salesforce is probably one of the clearest examples of this dynamic. It is not a simple villain story because Salesforce clearly solves real problems for real businesses at massive scale. It is valuable, mature, deeply configurable, and central to how many companies operate. But it is also an example of what happens when a platform becomes so specialized that the customer slowly reorganizes around the vendor. Apex, for example, is Salesforce’s own strongly typed, object-oriented programming language used to execute logic on Salesforce servers. That kind of proprietary extensibility can be powerful, but it also means that the deeper a company builds into the platform, the less portable that investment becomes. The code, the skills, the processes, the consultants, the admin patterns, and the mental model all become Salesforce-shaped. At some point, the customer is no longer just using Salesforce. They are adapting themselves to it.

That does not mean proprietary technology is automatically bad. There are plenty of cases where a company needs to create something proprietary because the generic version is not good enough. The problem is when proprietary technology stops being a way to deliver better outcomes and becomes a way to make escape more difficult. When that happens, the product becomes less interested in being elegant, flexible, or easy to reason about. The roadmap starts to reward deeper entanglement. The company may add more features, but those features are often designed to pull more of the customer’s world into the platform rather than making the customer’s world easier to operate. The moat gets wider, but it starts to feel less like protection and more like a wall.

The better version of this is a company that still wants to be the center of gravity, but does not need to make the customer feel trapped in order to stay there. Datadog is a good example. It is not cheap, and once a company has built serious observability practices around it, leaving would not be trivial. But the nature of the stickiness feels different. Datadog continues to invest heavily in product breadth, usability, and new capabilities, while also supporting OpenTelemetry, which is explicitly designed as a vendor-neutral, open source observability framework for generating, collecting, and exporting telemetry data. Datadog’s own documentation explains how to send OpenTelemetry metrics, traces, and logs into Datadog, which allows teams to get value from Datadog without necessarily making every instrumentation decision Datadog-specific.

That distinction matters. A company can still choose Datadog because it is the best place to observe its systems, correlate signals, manage incidents, and understand what is happening across the stack. But support for open standards changes the emotional contract. It tells the customer: we want you to stay because this is useful, not because your data and instrumentation are hopelessly tangled in something only we understand. That does not eliminate switching costs, but it makes them feel more honest. The cost of leaving comes from the fact that the product is deeply useful, not from the fact that the customer was slowly cornered.

Vercel has a similar shape in the web platform space. Vercel obviously benefits when teams deploy their applications on Vercel, and it has every incentive to make that experience as compelling as possible. But the core relationship with Next.js still leaves room for portability. Vercel’s own documentation says that Next.js works when self-hosting, while Vercel provides zero-configuration deployment and additional enhancements around scalability, availability, and performance. The Next.js documentation also describes self-hosting options such as running on a Node.js server, Docker, or static export. That does not mean every Vercel feature is portable in a perfect one-to-one way, and it would be naive to pretend there is no platform advantage in using Vercel. But the posture is different. The value-add is built around making the best path excellent, not making every other path impossible.

That is the happy medium more SaaS companies should aim for. A vendor should be allowed to create differentiated value. It should be allowed to build features that work best on its own platform. It should be allowed to make the hosted experience better than the self-managed one. That is the whole point of paying for software and infrastructure. But there is a meaningful difference between “this is better here” and “this only works here because we made sure it could not work anywhere else.” The first creates preference. The second creates resentment.

And resentment is an underrated business risk. It often does not show up immediately in renewal numbers because large companies move slowly. A frustrated customer may still renew for years because the cost of leaving is too high, the migration is too risky, or the internal expertise is too specialized. But that customer is no longer loyal in the real sense. They are waiting. They are watching for alternatives. They are quietly funding internal workarounds. They are asking architects to avoid deeper integration. They are telling teams not to use the vendor-specific feature unless absolutely necessary. The vendor may still have the account, but it has lost the customer’s imagination.

That is where the question changes. The customer stops asking, “How can we get more value out of this platform?” and starts asking, “How can we get out of here someday?” Once that shift happens, every new proprietary feature looks suspicious. Every pricing change feels extractive. Every migration path feels like a threat. Every sales conversation becomes defensive. Even useful features get filtered through the fear that they are just another hook. That is a very different relationship than the one great SaaS companies should want to have.

The best SaaS companies understand that openness is not the enemy of retention. In many cases, openness is what makes retention feel safe. When a customer knows they can leave, staying becomes a stronger signal. It means the vendor is still winning on merit. Open standards, clean APIs, reasonable data export, transparent pricing, strong documentation, and portability do not weaken a great product. They force the product to keep being great. They create the conditions for trust, and trust is a stronger moat than fear.

This is especially important in enterprise software because technical decisions become cultural decisions over time. A proprietary platform does not just affect architecture. It affects hiring, budgeting, delivery timelines, team structure, vendor management, and the way people think about solving problems. If a company builds too much around one vendor’s private universe, it can lose the ability to think clearly outside of that universe. That is when a tool becomes more than a tool. It becomes a constraint on imagination.

👉🏼
This is especially important in enterprise software because technical decisions become cultural decisions over time

None of this means companies should avoid deep platforms. Depth is often where the value is. Shallow tools are easy to leave because they are easy to outgrow. The real question is whether depth comes with leverage or captivity. A good platform makes hard things easier while preserving the customer’s ability to make future choices. A bad platform makes hard things possible only by pulling the customer deeper into a world they cannot easily exit.

References

© Karim Shehadeh
  • X
  • BlueSky
  • RSS
  • LinkedIn
  • StackOverflow
  • Github