What 'no vendor lock-in' actually means in 2026

"No vendor lock-in" usually means: you can fire your vendor tomorrow morning, take your data and your workflow logic with you, and have something running again within a week. If any of those three is missing, the phrase is marketing, not architecture.

The three places lock-in actually lives

People think lock-in lives in the contract. It doesn't. It lives in three technical layers, and the contract just describes who pays the exit cost.

Lock-in layer one: your data

You're locked in on data when getting your records out costs more than starting over. Common patterns: proprietary export formats that lose half the fields, paid "data extraction" line items that activate only on cancellation, schemas that only the vendor's own tools know how to interpret.

The fix is mundane: any system you depend on should let you run a SQL query (or its equivalent) and walk away with a clean CSV that opens in Excel. If your vendor charges extra for that, you don't own your data — you lease it.

Lock-in layer two: your model

The model is the most-hyped layer and the easiest to fix. Whether you use OpenAI, Anthropic, Google, or an open-weight model, the right architecture wraps the model call behind one function. Swapping providers should mean editing one file and rerunning your evals.

If switching models requires rewriting half your system, the lock-in isn't on the model vendor — it's in the way your system was built. That's the layer worth attention.

Lock-in layer three: your workflow logic

This is the one most people miss. If your business rules live inside a no-code tool's drag-and-drop UI, exporting them is essentially impossible. Even if the tool offers a JSON export, those JSON files are unreadable by anything else, and the logic dies the moment you change platforms.

The defensible move is to keep workflow logic in plain code or in human-readable rules (Markdown, Google Sheets, runbook entries) that any team member can read without the vendor's tooling. The execution layer can be proprietary; the intent shouldn't be.

How we structure ownership

Every system we build assigns these things to the customer's accounts, not ours:

• Database: your Postgres, your S3, your warehouse — never ours.
• Model API keys: in your secret store, billed to your card.
• Source code: in your repo (or, if we host it during the build, transferred to your repo at handoff).
• Workflow definitions: in plain TypeScript or YAML in your repo, not behind a SaaS UI.
• Logs and traces: in your observability stack — Datadog, Grafana, PostHog, whatever.

What we keep: our reusable building blocks, our patterns library, our delivery process. None of those are things you'd want to inherit on day one of running the system yourself.

What "fire us tomorrow" actually looks like

Concretely: you fork your repo, rotate the API keys, redirect the cron schedules to your team, and the system keeps running. You'd lose our future improvements. You wouldn't lose anything that's already shipped.

We've had two clients do this in the last three years — both because they hired in-house engineers who were better positioned to maintain the system than a contracted team. In both cases the handoff took less than two weeks.

Frequently asked questions

What's the realistic cost of switching automation vendors?

If your data is portable and your workflow logic is human-readable, the cost is one to three weeks of engineering time to rewire integrations. If either of those is missing, you're looking at a several-month rebuild — usually with significant data loss.

Are no-code tools always lock-in?

Not always. The good ones (Zapier, Make, n8n) export readable workflow definitions and use standard data shapes. The bad ones bury logic in proprietary state machines that don't survive an export. The test: can a developer who's never used the tool open the export and understand what the workflow does? If yes, you're fine. If no, you're locked in.

Do you require long-term contracts?

No. Month-to-month, with the codebase in your repo from day one. The leverage that keeps customers around should be the work being good, not the contract being expensive to leave.

The takeaway

If a vendor pitches "no lock-in," ask them to walk you through what happens the day you fire them. Where does the data live? Where does the workflow logic live? Who can maintain the code? If any answer is "well, you'd have to extract it through our tool," it's lock-in dressed in friendlier language. The honest version is shorter than the pitch.