The hidden revenue tax of vendor-coupled SaaS architecture

Most founders think vendor lock-in starts when they need to migrate. I don't think that's when it starts. It starts much earlier, the moment a business decision quietly becomes a technical one.

It took me a while to realize that.

Early in my career, I chose vendors for the same reasons everyone does: the best free tier, the cleanest API, a problem solved that I didn't want to spend two weeks building myself. Those were good decisions, and I'd probably make most of them again today. What changed wasn't how I chose vendors. It was how I started thinking about the relationship.

Every SaaS company is trying to build a successful business. So are you. At first, those goals usually align. An email provider wants to attract startups, so it offers a generous free plan. An AI provider launches the best model on the market. An authentication platform promises you'll have users signing in before lunch. Everyone wins.

Then both businesses grow. Your needs become more complex. Their priorities evolve. Maybe the free tier disappears. Maybe a feature you've built your product around moves behind an Enterprise plan. Maybe another provider suddenly offers better pricing or better quality. Sometimes the product itself changes direction.

We've all seen this play out. Loom gradually shifted toward larger organizations after joining Atlassian, and that wasn't a betrayal of early customers, it was a business choosing where it believed its future was. More recently, Cursor changed how Composer usage was allocated. Whether you agreed with the decision or not isn't really the point: Cursor was making a decision for Cursor. That's what healthy businesses do. One day Refract will probably make decisions that don't perfectly fit every customer either. Business is business, and companies optimize for the future, not for how long a relationship has existed.

Once I accepted that, something else clicked. Vendor coupling isn't really about vendors. It's about ownership. If another company's roadmap can quietly dictate how difficult it is for you to evolve your own business, you've given away more control than you probably intended.

That's the hidden tax. Not migration, not SDKs, not adapters. The tax is losing the freedom to make product decisions because your architecture has become part of someone else's business model.

What is the hidden revenue tax of vendor-coupled SaaS architecture?

The hidden revenue tax is the cost you pay every time your business changes and your architecture struggles to keep up. Notice I didn't say "when your vendors change." Your vendors are expected to change. The real question is whether your architecture expected it too.

I've watched teams ship features incredibly fast by calling provider SDKs directly from resolvers, webhook handlers, and background jobs. Nothing looked wrong, until the business evolved: a new pricing model, annual billing, grandfathered plans, usage-based limits, enterprise contracts, regional pricing. Suddenly a product conversation had become an engineering project, and nobody had decided to rewrite the billing system. The architecture simply made it unavoidable.

Looking back, I don't think those teams had an engineering problem. They had accidentally let implementation details become part of the product. That's a very different problem, and it's usually invisible until the day it costs you a quarter.

Why does vendor coupling slow pricing and packaging changes?

Because architecture tends to age in silence. The feature ships, the sprint closes, customers are happy, and everything feels successful. Then, six months later, someone asks a perfectly reasonable question: what if existing customers keep their old price?

That question sounds commercial. The answer often isn't. Now someone needs to understand Stripe subscriptions, webhook ordering, invoice states, entitlement logic, feature flags, and historical migrations before anyone can confidently answer what should have been a product decision. That's the tax.

Not because Stripe is bad. Stripe is doing exactly what Stripe should be doing. The same is true for OpenAI, or Supabase, or Resend, or whichever provider you happen to depend on. They're building products, evolving pricing, improving APIs, changing roadmaps, running businesses. Your responsibility isn't to stop them doing that. Your responsibility is making sure your own business isn't forced to evolve at exactly the same pace, in exactly the same direction.

That's why I stopped thinking about integrations as implementation details. They're business relationships. Like any relationship, they work while both sides benefit, and sometimes they stop being the right fit. You should be free to leave without rewriting your product.

Where does vendor coupling hurt revenue first?

In my experience, it almost never starts with infrastructure. It starts where customers experience value: billing, entitlements, authentication, authorization, notifications, usage metering. Those systems sit at the intersection of your product and someone else's, which is exactly why they deserve more attention than they usually get.

Take billing. Stripe has excellent APIs, excellent documentation, excellent reliability. None of that changes the fact that Stripe models subscriptions according to Stripe's understanding of subscriptions. Your product almost certainly doesn't. The same pattern shows up everywhere: OpenAI thinks in models, your customers think in features. Supabase thinks in authentication, your customers think in accounts. Resend thinks in email delivery, your customers think in notifications. Those differences sound subtle. Over time, they become architectural.

And they rarely show up as a technical failure first. They show up as a business one. The free tier that made a vendor an easy first choice disappears once you cross a usage threshold. A feature your product quietly depends on moves behind a plan you're not ready to pay for, and now an upgrade you never scheduled becomes the only way to keep a feature you already shipped to customers. Or the pricing model itself changes and you're not grandfathered into anything, so a cost that used to scale gently with your business jumps in one step instead. None of this is malicious. It's just what happens when a vendor's roadmap and your roadmap were never actually the same roadmap, they just looked like it for a while.

It's why access-control failures remain one of the most common application vulnerabilities according to OWASP (OWASP A01 Broken Access Control), and why providers like Stripe invest so heavily in webhook reconciliation and retry strategies (Stripe webhook delivery and retries). As your application grows, those implementation details become harder to ignore. The question is whether your business grows around them, or whether they stay isolated behind boundaries you own.

What changed in how I design software?

Once I started thinking about vendors as business relationships instead of integrations, a lot of architectural decisions became easier. I stopped asking "how do I integrate Stripe?" and started asking "what part of my business should Stripe actually own?"

The answer was surprisingly little. Stripe should process payments; it shouldn't define how subscriptions exist inside my application. OpenAI should generate text; it shouldn't dictate how AI capabilities are exposed to my customers. An email provider should deliver emails; it shouldn't become the place where my notification rules live. Every provider should own its capability. My application should own the business.

That shift sounds philosophical, but it changes very practical things. Business rules stop leaking into webhook handlers. Pricing stops depending on provider-specific concepts. Changing an implementation becomes a technical decision instead of a company-wide initiative. None of that removes complexity. It simply moves it to where it belongs.

The boundaries I care about

Over time I realized I wasn't really building abstractions. I was protecting ownership.

Some parts of a product naturally belong to the business you're building: pricing, packaging, feature access, user permissions, usage limits. Those aren't implementation details, they're part of your product's identity. If changing an email provider forces you to rethink notification rules, something probably owns more than it should. If replacing a billing provider means rewriting how subscriptions work, you've likely coupled your business to someone else's model.

The same goes for AI. Models will improve, prices will change, new providers will appear, and old ones will disappear. If every model upgrade forces product-wide changes, you've accidentally let your AI provider define part of your architecture. I try very hard not to let that happen.

The question I now ask before adding any dependency

I don't have a checklist for choosing vendors. I have one question.

If this company changes direction in two years, how difficult will it be for my business to change direction too?

That's it. Sometimes the answer is "it doesn't matter," an analytics platform might be deeply integrated without creating much business risk. Sometimes the answer is obvious: billing almost always deserves stronger boundaries, authentication usually does too, and AI increasingly belongs in that category.

The goal isn't to eliminate coupling. That's impossible. The goal is deciding, consciously, where it belongs.

What good boundaries actually buy you

People often talk about optionality as though it's an architectural luxury. I don't think it is. Optionality is what allows a business to keep learning.

Imagine your customers ask for a pricing model your current billing provider doesn't support elegantly. Or another AI provider suddenly becomes dramatically cheaper. Or a competitor ships a capability you've been waiting for. Those moments shouldn't trigger an architectural crisis, they should trigger a product discussion. That's the difference.

Good boundaries don't make migrations free. They make them proportionate. Changing one provider should feel like changing one provider, not rebuilding the product around a new interpretation of the same business.

How I evaluate my own architecture

I don't look at class diagrams. I don't count interfaces. I don't care whether a project follows Clean Architecture perfectly. Instead, I imagine a series of uncomfortable conversations.

What if we doubled our prices? What if enterprise customers keep their old plans forever? What if we switch AI providers next quarter? What if we replace Stripe? What if this vendor removes the feature we're relying on?

Those questions tell me far more about an architecture than its folder structure ever will. If every answer starts with "we'd have to rewrite," I've probably found a boundary worth strengthening.

This is why Refract looks the way it does

People sometimes ask why Refract has explicit boundaries around billing, RBAC, AI providers, queues, and storage. It isn't because I enjoy abstraction for its own sake. It's because I've spent enough time watching successful products evolve to know how this goes.

Businesses change. Pricing changes. Markets change. Providers change. That's the normal lifecycle of software. I don't know which AI provider will lead in three years, which billing platform will offer the best pricing, or which authentication provider will become the default. Pretending I do would be arrogance. I'd rather assume they'll all evolve, and build something that can evolve with them.

Final thoughts

Every vendor relationship starts because both sides benefit. There's nothing wrong with that, it's exactly how healthy businesses should work. The mistake is believing today's relationship will remain the right one forever.

Companies optimize for where they're going. So should you.

I don't build boundaries because I expect vendors to disappoint me. I build them because I expect every business, including my own, to keep changing. If that means replacing a provider one day, I'd like that to be a technical project, not a product rewrite.

Because at the end of the day, your vendors are responsible for running their business. Your architecture should make sure you're always free to keep running yours.