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.
- Logic in platform-specific scripts (Apps Script, Zapier Zaps, Airtable Automations)
- Data in proprietary formats with no clean export path
- Integrations that only work with one vendor's ecosystem
- Dependencies on vendor-specific APIs that don't exist elsewhere
Layer 1 (Trigger): Thin glue. Platform-specific—Apps Script, Cron, webhook. Its job: call your service. No business logic.
Layer 2 (Logic): Portable service. Docker container. Version-controlled. Runs anywhere—Cloud Run, Lambda, your own server. All business logic lives here.
Layer 3 (Data): Standard storage. Postgres, S3-compatible, etc. Exportable. Not tied to one vendor.
Switch clouds? Change the trigger and the deployment target. The logic and data stay the same.
Ask: If we had to move off this platform in 90 days, what would we rebuild? If the answer is "everything," you're locked in. If the answer is "just the triggers and config," you're portable.
- Building critical logic in 'no-code' platforms—convenient now, expensive later
- Assuming you'll never need to switch—you might, and the switch cost compounds
- Treating lock-in as acceptable "because we're moving fast"—it slows you down when you need to change
- Not separating trigger from logic—they should be swappable independently
See it in action
Want to audit your automation for lock-in risk?