What creates lock-in?
View details →
Vendor Lock-in
The best automation platform today might be wrong tomorrow. Vendor lock-in is the tax you pay when you can't switch. The goal: build so you can leave without rewriting everything.
- Lock-in = the cost of leaving exceeds the cost of staying, even when you want to leave
- Trapped logic: business rules live in platform-specific scripts (Apps Script, Zapier) that can't move
- Trapped data: export is hard, incomplete, or format-locked
- Three-layer architecture: thin triggers call portable services. Logic lives in Docker, not Zapier.
- The test: can you switch clouds or platforms without rewriting core logic?
Real-world example
You automated everything in Zapier. Now you need to switch to Google Cloud.
Zapier runs 50 workflows. Logic is in Zaps, not code. Data flows through Zapier. Your contract is up and costs are rising.
- Lock-in: The logic is Zapier-specific. You can't export Zaps to GCP. You'd rebuild from scratch.
- Contrast: Triggers in Zapier call your API. Your API is a Docker container. Same container runs on Cloud Run, Lambda, or a VPS.
- Switch: Point Zapier (or replace it with Cloud Scheduler + HTTP) at the new endpoint. Same logic. Different trigger.
- The logic was never in Zapier—it was in your code. Zapier was just the trigger layer.
- Portable = you choose where to run. Lock-in = the platform chooses for you.
Lock-in happens when the platform owns your logic. Keep logic in code; use platforms only as triggers.
The three-layer antidote
View details →
The portability test
View details →
Common mistakes
View details →
See it in action
Want to audit your automation for lock-in risk?