When You Think You're Open, But You're Inadvertently Locked In

Scott Brinker has articulated a critical shift in how enterprises think about martech: the competitive advantage is no longer in opinionated applications, but in the foundational infrastructure beneath them. As AI makes custom applications increasingly tractable, organizations want to buy infrastructure while building their own differentiated solutions—not licensing predetermined workflows designed for generic use cases.

That insight is sound. But enterprise buyers are missing what that shift actually demands.

The Enterprise's Smart Move

Over the last two years, a pattern has emerged. CIOs are deliberately building infrastructure agility into their technology stacks. Multi-cloud strategies are no longer edge cases, they're policy. Cloud service provider optionality isn't a hedge, it's architecture. Same with communication channels—SMS, push, email, WhatsApp. The reasoning is sound: single-provider dependency is a single point of failure. Why lock your organization to one infrastructure vendor when you can maintain the agility to switch based on business needs, cost, or risk?

This is the right move. It reflects board-level concerns: single-vendor dependency is now understood as a business continuity risk. When infrastructure outages or geopolitical events can cascade through revenue-generating systems in hours, optionality stops being a technical preference and becomes strategic resilience.

Then enterprises go buy a MarTech vendor.

The Blind Spot

Here's what's happening. While your infrastructure team is building agility into your stack—multi-CSP, modular architecture, communication channel independence—your MarTech vendor is locked into choices that negate all of that.

You deploy your customer data platform on AWS because AWS is part of your multi-cloud strategy. The vendor you chose? They're only built on AWS. You just inherited AWS dependency at the application layer, even though you were deliberately avoiding it at the infrastructure layer.

You build communication agility into your customer engagement stack—the ability to send via SMS through Twilio, then switch to Sinch if needed. Push through APNs, then move to Braze. Email through SendGrid, then to Mailchimp. Your MarTech vendor? They've baked in a single communication provider. They can't switch. You just introduced a bottleneck you didn't know you had.

The vendor isn't wrong. They're just not built for the world your infrastructure team is building. Most enterprise procurement processes don't ask about infrastructure portability—they ask about features, ROI, integration breadth. It's a natural gap. Infrastructure flexibility isn't a checkbox on an RFP.

This is the blind spot: infrastructure decisions that undermine the very agility your CIO is building into the broader stack.

Proof in Motion

This isn't theoretical. On March 2, 2026, drone strikes targeted AWS data centers in the UAE and Bahrain. S3, EC2, and RDS went down. The regional impact was immediate and cascading: Snowflake, banking platforms, fintech applications, e-commerce systems across the Gulf went offline. Full recovery took 72+ hours.

Here's what happened next.

MarTech vendors that had invested in infrastructure agility—the ability to swap cloud providers, migrate customer engagement workloads, and pivot communication infrastructure—recovered in hours. Their customers stayed online. Customer engagement continued. Real-time decisioning stayed operational.

MarTech vendors locked into AWS? They waited. Their customers' communication infrastructure sat dark. Some moved to backup communication providers (SMS, email) if they had them. Most didn't. For 72 hours, marketing operations in the region were offline. Revenue impact was immediate and measurable.

Snowflake, a critical data infrastructure vendor, experienced the same constraint. Locked to AWS region. When AWS went down, Snowflake went down. Organizations that had built cloud-agnostic data architectures (multi-cloud queries, cross-region failover) suffered degraded performance. Organizations locked to Snowflake-on-AWS suffered total outages.

The enterprises that had made the smart infrastructure choices—the multi-CSP strategy, the communication channel agility—found that advantage erased by a vendor locked into single-provider architecture.

One vendor could move. One couldn't. The difference wasn't technology sophistication. It was the infrastructure agility that architecture decisions had (or hadn't) enabled years before the crisis arrived.

What Control Actually Means

You don't need to own infrastructure yourself. That's not the answer. But you do need to require your vendors to enable your agility. That's the distinction.

You should be asking your MarTech vendors: Can you run on multiple cloud service providers? Not as a future roadmap item, but now. Not as a backup plan, but as a standard deployment option. If the answer is no, or "maybe in 2027," you've just introduced infrastructure dependency you didn't intend.

Same question for communication infrastructure. If your MarTech platform can only send SMS through one provider, and that provider goes down or becomes unavailable in your geography, what happens to customer engagement? If your platform can't swap between email providers, you're one outage away from losing a channel. If the answer is "nothing we can do"—you've just chosen a vendor that constrains your operational agility.

This becomes a contract requirement. Not as penalty language, but as due diligence. The same way you'd ask about uptime SLAs or data residency requirements, you should ask about infrastructure agility.

Can the vendor switch cloud providers if needed? Can they maintain customer communication across multiple SMS providers, email gateways, push networks independently? Can you, as the customer, require a migration without renegotiating your entire license agreement? These aren't exotic requirements. They're the basic elements of infrastructure agility. They're table stakes for a MarTech vendor in 2026.

The Question for Enterprise Buyers

You've made the right infrastructure choices. Multi-cloud isn't a buzzword in your organization, it's policy. Communication channel agility is embedded in your stack. You've thought through redundancy and optionality.

The next layer of that thinking: extend the same rigor to your software vendors.

Your CIO has built an agile infrastructure. If your MarTech vendor's architecture doesn't support that agility, you've introduced a constraint you didn't know you had. One team is planning for optionality. The other team's architecture assumes it away. These don't collide until crisis forces it—geopolitical events, infrastructure outages, regulatory shifts. Until you need to move fast and your vendor's architecture won't let you.

The due diligence question isn't about features or capabilities or integration breadth. It's about whether the vendor's infrastructure design enables your agility or constrains it.

The Vendors Building for This

Forward-thinking MarTech vendors are designing differently. They're architecting for cloud-agnostic deployment: the ability to run on AWS, GCP, Azure without architectural rewrites. They're building communication infrastructure that treats providers as swappable components—SMS through Twilio today, Sinch tomorrow. Email through SendGrid or Mailchimp. Push through APNs or Braze. Not as multi-vendor chaos, but as operational optionality baked into the platform.

These vendors treat infrastructure agility not as a disaster recovery feature, but as operational architecture. It's how they guarantee customer engagement stays live when geopolitical or infrastructure events force migration. It's how they can promise: "If this cloud provider becomes unavailable, we're operational on another in hours, not weeks."

The evaluating question for your next MarTech vendor is straightforward: Can you deploy on multiple cloud providers as a standard architecture, not a future feature? Can you swap communication providers without rearchitecting? Can we add a new SMS gateway in minutes, not quarters? Can we migrate regions in a maintenance window?

Not every vendor needs to be multi-cloud today. But they should have a path to it, and that path should be built into architecture, not left for a future rewrite.

That's the question that separates vendors who are prepared for the infrastructure landscape of 2026 from those still building for 2020.