A few years ago, a company I know built its entire customer communications workflow on a startup called Intercom competitor that I’ll leave nameless. Deep integration, trained support staff, years of historical data. Then the startup got acqui-hired, the product went into maintenance mode, and six months later the API started returning errors with no explanation. The company’s data was technically exportable, but the export format was a proprietary JSON schema that nothing else could read. They owned a subscription. They did not own their workflow, their data in any usable sense, or their continuity.
This is the quiet catastrophe hiding inside most B2B software relationships. The startup gets credit for solving your problem. Nobody talks about the terms under which you’re allowed to keep that problem solved.
The License Is Not What You Think It Is
When you pay a startup for software, you are almost never buying software. You are buying a revocable license to access software, subject to terms that can change with thirty days notice, if the company even bothers with that courtesy. Read almost any SaaS agreement closely and you will find language to this effect: the company grants you a limited, non-exclusive, non-transferable, revocable license to use the service during the subscription term.
Revocable. That word is doing a lot of work.
The distinction that matters legally is between a license and a purchase. When you buy a physical book, you own the physical object. When you buy a software license, you own nothing except the right to use something under conditions set entirely by the other party. Courts have repeatedly upheld this interpretation. In Vernor v. Autodesk (2010), the Ninth Circuit ruled that software buyers who thought they had purchased copies were actually licensees, bound by Autodesk’s terms even after resale. The principle has only expanded in the SaaS era, where you never even receive a copy.
Your Data Is a Separate Problem from Your Software
Most customers, when they think about vendor lock-in, think about the software itself. Can I switch? What’s the migration cost? These are real questions, but they miss the harder problem: your data.
Data portability provisions in SaaS contracts are almost universally inadequate. Companies promise export functionality. What they deliver is a CSV that loses relational structure, an XML file that requires the vendor’s schema documentation to interpret, or an API endpoint that works until it doesn’t. The data exists. Using it outside the original context is another matter entirely.
Healthcare, legal, and financial software vendors have spent years building products where the export problem is effectively a feature. Your data goes in easily. Getting it out in a form a competitor can import requires months of engineering work, which means switching costs are structural, not contractual. The lock-in is architectural.
This is worth thinking about before you sign, not after. Ask specifically: if you shut down tomorrow, what format does my data come out in, and can I demonstrate that a competitor can import it? If the answer is vague, that vagueness is information.
What Happens When the Startup Dies
Startups fail. This is not cynicism, it’s arithmetic. When a startup fails or gets acquired, the terms you agreed to become essentially meaningless because there is no longer a counterparty with an incentive to honor them.
Acquisitions are the more common scenario, and in some ways more dangerous than outright failure. When a company fails, you know it’s over and you start planning. When it gets acquired, you often get a transition period that creates false comfort while the acquirer evaluates whether your use case fits their roadmap. If it doesn’t, the product gets deprecated on a timeline you don’t control. This is exactly what happened to customers of products like Parse (acquired by Facebook, shut down in 2017) or Mailchimp features that got quietly discontinued after the Intuit acquisition.
Some contracts include data preservation clauses that survive termination. Most don’t. Some include escrow arrangements where source code gets deposited with a third party in case of company failure. These are real and worth negotiating for, particularly if the software is genuinely mission-critical. They are also almost never offered in standard contracts and rarely requested by buyers who assume they’ll get around to switching before anything bad happens.
The Leverage You Have Before You Sign
Negotiating with a well-funded startup feels uncomfortable because they project confidence and you feel lucky to be onboarded. Ignore that feeling. The time you have leverage is before you sign, and the things worth negotiating are specific.
Data portability in a defined, open format is the first thing to get in writing. Not just “export functionality” but a named format (CSV with a documented schema, SQL dump, JSON-LD, whatever makes sense for your domain) that a third party can independently confirm is usable. Second, termination notice periods. Thirty days is industry default. Ninety or a hundred and eighty days is achievable for enterprise contracts and worth asking for. Third, most-favored-nation pricing clauses, which protect you if the startup decides to raise prices dramatically on existing customers while offering better rates to new ones.
None of this is adversarial. Any startup worth working with will recognize that customers who understand what they’re agreeing to are better long-term customers. If a startup refuses to engage with basic data portability questions, that tells you something important about how they think about the relationship.
Ownership Is a Framework, Not a Feeling
The mythology of software purchasing is that paying money creates a relationship of ownership. It doesn’t, and in the SaaS world it never really did. What you are doing when you adopt a startup’s product is making a bet that the company will survive, stay aligned with your interests, and honor the spirit of its commitments even when honoring the letter becomes inconvenient.
That’s not inherently a bad bet. Plenty of startup software relationships work out fine for years. But understanding what you actually own, which is a license, not a product, and understanding what protects that relationship, which is specific contractual language, not goodwill, is the difference between a calculated dependency and an accidental one.
The companies I’ve seen get burned were not naive. They were busy. They deprioritized the fine print because the product worked and the startup seemed solid. That’s when it matters most to slow down and read carefully, because the scenario where the contract matters is exactly the scenario where you won’t have time to think about it.
