How locked in is your app?

Paste your package.json and any config (vercel.json, wrangler.toml, fly.toml, serverless.yml, Procfile…). You get an instant read on how tied your app is to one provider — line by line — and exactly what it would take to leave. No signup. Nothing leaves your browser.

Why lock-in is the thing to measure

Every visible cloud horror story — the surprise five-figure bill, the provider that 10x'd its pricing, the outage you couldn't route around — has the same root cause underneath it: you were trapped on infrastructure you don't control, and leaving cost more than staying. Lock-in is that trap, measured before it closes.

It isn't created by hosting somewhere. It's created by adopting a provider's proprietary primitives — Vercel's ISR and edge runtime, Cloudflare's Durable Objects and Workers KV, AWS's DynamoDB and Lambda event shapes, Firebase's Firestore. A Postgres database behind a standard driver is portable; the same data behind a managed proprietary store is a re-platforming project. The difference is invisible until you try to leave, which is the worst possible time to find out.

This checker makes it visible early. It reads the dependencies and config keywords that signal coupling, weights each by how hard it is to unwind, and shows you the inventory so you can verify every line yourself. That's the whole point — trust by inspection, not a number you have to take on faith.