How tightly the code is bound to specific vendors and clouds — and what it would cost to leave if pricing, terms, or reliability forced the issue.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: measure how dependent the product is on specific third-party vendors and clouds, and estimate the real cost of leaving — so lock-in is a known, priced risk rather than a surprise.
Read-only pass. Read the dependency surface, infra, and integration code; change nothing. Your only write is the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
vendor-specific APIs and SDKs threaded through the code with no abstraction
where the data lives and how hard or costly it is to extract and move
one provider whose outage takes the whole product down
proprietary databases, queues, and auth with no portable equivalent
usage-based costs that scale badly; terms that can change under you
where an adapter would isolate a vendor versus bare calls scattered around
a realistic estimate of the effort to migrate the top one or two dependencies
One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.
Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
List the vendors the product relies on.
Proprietary coupling — vendor-specific APIs and SDKs threaded through the code with no abstraction.
Rank by likelihood × pain.
Create LOCKIN.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:vendor-lock-in.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-vendor-lock-in:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=93 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/93.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: Vendor Lock-In Audit You are working inside this repo. Mission: measure how dependent the product is on specific third-party vendors and clouds, and estimate the real cost of leaving — so lock-in is a known, priced risk rather than a surprise. Read-only pass. Read the dependency surface, infra, and integration code; change nothing. Your only write is the report file. ## Phase 1 — Map the dependence - List the vendors the product relies on: cloud, database, auth, payments, email, AI, analytics. - For each, note how deeply it is woven in: bare SDK calls everywhere, or behind an interface. - Identify which vendors are load-bearing — an outage or ban would stop the product. ## Phase 2 — Audit through 7 lenses 1. **Proprietary coupling** — vendor-specific APIs and SDKs threaded through the code with no abstraction 2. **Data gravity** — where the data lives and how hard or costly it is to extract and move 3. **Single points of vendor failure** — one provider whose outage takes the whole product down 4. **Managed-service dependence** — proprietary databases, queues, and auth with no portable equivalent 5. **Pricing & terms exposure** — usage-based costs that scale badly; terms that can change under you 6. **Portability seams** — where an adapter would isolate a vendor versus bare calls scattered around 7. **Exit cost** — a realistic estimate of the effort to migrate the top one or two dependencies ## Phase 3 — Curate - Rank by likelihood × pain: a vendor with volatile pricing and deep coupling outranks a swappable one. - Distinguish healthy dependence (use the managed service) from risky lock-in (cannot leave if you had to). - For the worst, name the cheap abstraction that would buy optionality without a rewrite. ## Phase 4 — Report Create `LOCKIN.md` at repo root: 1. **Dependence map** — vendor · surface · coupling depth · estimated exit cost 2. **Risks** — ranked by likelihood × pain, each with what triggers it 3. **Cheap optionality** — the adapters or seams worth adding before you need them 4. **Contingency** — for each load-bearing vendor, the rough plan if it had to change Start the report with today's date. If `LOCKIN.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - Depending on a vendor is fine; being unable to leave one is the risk - Price the exit before you are forced to pay it - No third-party vendors in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding. - If a `reports/` directory exists at the repo root, write the report there instead of the root. - Before asking, present the top findings as a ranked list in plain words - Report only — end by asking which lock-in risks to address first
reports/ directory exists at the repo root, write the report there instead of the root.Map merged-PR to production; every manual step is a finding. Includes the rollback-readiness verdict.
Expensive queries, chatty API loops, unbounded storage, oversized resources — savings ranked by effort.
The 3am table — for each failure scenario: how you'd detect it, how you'd respond, and the gap in between.
Every knob, var, and magic value — where config sprawls, where environments drift, what explodes at boot versus at 3am, and which secrets hide in plain sight.