Here's the thing about vendor lock-in that most people get wrong: it's not usually malicious, and it's rarely accidental. It's the inevitable output of rational business decisions made during the moments when nobody's thinking about it.
Start from where every vendor is at day one. You're trying to build something useful quickly. You need to move fast, prove value, get traction. So you make the obvious call: lean on your own infrastructure. Build proprietary integrations. Store data in ways that make sense for your system. Use APIs that only your platform understands. None of this is sneaky. It's just efficient.
Then your product gets good. Customers like it. They start building workflows around it, feeding it their data, connecting it to their other tools through those proprietary integrations. The value they get from your platform starts compounding. They're not just using you for one thing anymore; they're using you for three things, which makes the fourth thing you add even more valuable to them.
At this point, something interesting happens. The vendor doesn't suddenly flip a switch to "lock-in mode." Instead, they just keep making the same efficient decisions. When they build new features, it makes sense to build them using the same architecture. When they expand their platform, they naturally expand using tools and connections they've already built. When they think about integrations, they think about what makes sense for their roadmap, not about how easy it would be for customers to leave.
After a few years of this, you've got a situation where leaving is genuinely difficult. Not because anyone plotted it, but because the architecture that made the most sense in year one, year two, and year three has accumulated into something that's deeply integrated. Moving data out is painful. Rebuilding workflows is painful. Training people on a new tool is painful. The switching costs are real and enormous, but they emerged from a series of straightforward business decisions, not from some Machiavellian master plan.
The remarkable part is that this actually serves customers reasonably well for a long time. That lock-in exists because the platform became genuinely valuable. You don't leave something you depend on. So the vendor grows their revenue, their product improves, and customers get more features. Everyone wins until the moment someone asks the question: "What if we wanted to leave?"
That's when lock-in feels intentional, because by then it is. But by "intentional" what I mean is that the vendor has now made a different kind of decision: they've decided that the lock-in is fine, because they've built something good enough that customers don't want to leave anyway. There's no active effort to trap people. There's just a recognition that the moat they've accidentally built is valuable, and maybe they don't need to make leaving easier.
This is where the roadmap decision lives. Not in some dark boardroom meeting, but in a series of quiet choices about what to prioritize. You can make your platform work better in isolation, or you can make it easier to integrate with your competitors. You can improve your core features, or you can invest in data portability. You can build deeper into your ecosystem, or you can build bridges out of it.
Almost everyone chooses the isolation path. Not because they're evil, but because it's harder to sell better integration as a feature than it is to sell a new capability. Shareholders don't get excited about portability. Roadmap committees don't light up for switching ease.
So the lock-in persists, not as an accident and not as a conspiracy. Just as the path of least resistance that happened to calcify around a genuinely useful product.