A founder once told me he wanted to avoid using AWS because he was worried about vendor lock-in. He was pre-revenue, building with two engineers, and had raised $300K to get to his first customers.
I asked him what his alternative was. He said he was thinking about building his own deployment infrastructure using bare metal servers he would manage himself.
I did not convince him that day. He spent three months on infrastructure before returning to AWS. He lost a co-founder in the process who was tired of working on servers instead of the product.
The fear of vendor lock-in is real, but it is applied with almost no discrimination between situations where it matters and situations where it is a distraction. This piece is my honest assessment of both.
The Actual Costs of Vendor Lock-In
Vendor lock-in has real costs when it materializes. Understanding what those costs actually are makes it possible to evaluate them honestly rather than reactively.
The switching cost. If you use AWS S3 for object storage and decide to switch to Google Cloud Storage, the actual work is: updating your storage client code (usually one library import), migrating your existing files (a one-time data transfer), and updating any AWS-specific bucket permissions to GCS equivalents. For most applications, this is a two-week engineering project. The data migration is the hard part, and its cost scales with data volume, not with how long you have been on AWS.
Pricing risk. If AWS raises their prices significantly, or if you discover that a particular service has pricing that does not work at your scale, you need to be able to switch. The question is how long it takes and how much it costs. For commodity services (compute, storage, networking), switching is painful but feasible. For proprietary services with no equivalent elsewhere (some AI/ML services, some specialized database services), switching requires rearchitecting.
Capability constraints. If a vendor's capabilities limit what your product can do, that is the real lock-in risk. You have built product features around an API that does not support the capabilities you need for your next product milestone, and switching means rebuilding the integration.
The vendor going away or changing terms. A vendor shutting down or dramatically changing pricing or API terms is the lock-in scenario founders most fear. It is also the least common for established infrastructure vendors. AWS, Google Cloud, Stripe, Twilio - the risk of any of these disappearing or changing their core APIs in breaking ways is low. The risk for smaller, less established vendors is higher.
When Lock-In Is Actually Fine
The vast majority of vendor decisions at an early-stage startup involve lock-in that is fine. Here is the honest list:
Cloud infrastructure (AWS, GCP, Azure) lock-in is fine for most startups. The switching costs are real but not catastrophic, and the cost of building cloud-agnostic infrastructure is higher than the expected switching cost over any reasonable time horizon. Companies that spend engineering resources on "cloud portability" are spending money on a problem they are unlikely to have.
Stripe for payments is fine. Stripe has become the de facto standard for startup payments, has best-in-class developer experience, and has never, to my knowledge, made a pricing or API change that forced a mass migration. The lock-in risk of Stripe is theoretical. The cost of evaluating alternatives for a startup is real.
Sendgrid or Postmark for email is fine. Email delivery is commodity infrastructure. The "lock-in" is your contact lists and your template code. Both migrate in hours to days.
Auth0 or Cognito for authentication is fine. Authentication is genuinely hard to build well. The "lock-in" is a migration of users to a new auth system, which is a real operation but a manageable one. The alternative - building authentication from scratch - has a long tail of security implications that almost never go well for companies doing it for the first time.
Shopify for e-commerce (until the constraints are real, as I discussed in the e-commerce article) is fine. Twilio for SMS is fine. Segment for analytics is fine.
The common thread: for commodity services with multiple viable alternatives and reasonable switching costs, the decision to use them should be based on what serves the current needs best, not on a theoretical future switching scenario.
When Lock-In Is a Real Risk
There are situations where lock-in genuinely matters and deserves serious consideration.
Proprietary data formats. If a vendor stores your data in a format that is difficult to export, that is a real lock-in risk. Before choosing any data storage vendor - databases, analytics platforms, data warehouses - verify that you can export your data in a standard format and that the export process is practical at scale. The specific question: if I needed to migrate off this platform, how would I get all of my data out, in what format, and how long would it take?
AI model lock-in. As AI capabilities become more central to product value, the risk of building a product that only works with one AI provider's API is growing. The LLM providers have different capabilities, pricing, and rate limits. If your product's core value proposition depends on a specific capability from one provider, you should design your integration to be swappable. This is not hard - it usually means abstracting the AI calls behind an interface your application code talks to, with different providers as implementations.
Marketplace and platform lock-in. If you are building a business that distributes through the Apple App Store, Amazon marketplace, or another platform, the lock-in is more existential than technical. The platform can change its terms, its algorithm, or its fee structure in ways that fundamentally change your business. This is a business strategy risk, not primarily a technical one.
Deep integration with proprietary workflow tools. If your product is deeply integrated with a specific enterprise software system (a particular ERP, a particular CRM) using proprietary APIs, you have tied your product's capabilities to that vendor's API decisions. If they deprecate an endpoint, change access terms, or go away, your integration breaks. The mitigation is to abstract your integrations behind a normalized internal data model.
The Framework for Evaluating Lock-In Risk
For any vendor decision, I use a simple framework:
What is the cost of switching if I need to in 18 months? If the answer is "two weeks of engineering work," the lock-in risk is low. If the answer is "six months of rearchitecting," it is worth taking seriously.
What is the cost of not using this vendor's service at all? This is the comparison that gets missed. The alternative to Stripe is not "use a different payment processor." The alternative is "spend four months building your own payment integration from scratch." The lock-in cost needs to be compared to the build cost.
How central is this vendor to my product's core value proposition? Infrastructure is different from core capability. If a vendor provides infrastructure (compute, storage, networking), switching is painful but the product still exists. If a vendor provides a capability that is central to what your product does, the dependency is deeper.
Is the vendor established and does the service have competitive alternatives? Stripe is established and has competitive alternatives. A startup offering a specialized AI capability is neither. The risk profile is different.
The Anti-Pattern That Wastes the Most Engineering Time
The anti-pattern I see most consistently in startups worried about lock-in: building abstraction layers that nobody actually uses.
An engineer, worried about database lock-in, builds an ORM layer that "works with any database." The company uses PostgreSQL for the next five years and never evaluates switching. The abstraction layer added two months of engineering work and ongoing maintenance overhead to protect against a decision that was never made.
The same pattern with cloud storage, with authentication, with analytics. Engineering effort spent on theoretical flexibility that is never needed.
The better use of that engineering time: build the product. Acquire customers. Get to a scale where the lock-in decisions have real consequences, and then address them with the information of knowing which vendor decisions are actually constraining you.
Early-stage startups have one resource that is more scarce than money: engineering time. Spending it on theoretical future problems is a luxury that most startups cannot afford.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr