Vendor Lock-in Escape Plan: A Dependency Triage and Migration Handbook for Solo Teams

Hidden inside every vibe coder's architecture diagram is an invisible invoice. Your app runs on someone else's auth service, your data lives in someone else's database, your billing flows through someone else's payment gateway, your emails leave through someone else's SMTP — you think you're "building independently," but you're really renting a life in the gaps between seven or eight SaaS companies. They raise prices, your prices go up. They change terms, your product changes with them. They shut down, your project dies alongside them.

This is not alarmism. This article is about one thing: how a one-person team, with one person's resources, can triage every external dependency and write an "escape plan" for each critical one. The thesis up front — lock-in itself is not the problem; lock-in without a plan is. Mature teams hedge with contracts and lawyers. A solo team hedges with something else: exportable data, standard protocols, and an escape route rehearsed once a year.

1. Why Lock-in Is Lethal for Solo Teams: Both Edges of the Lever

Here's a counterintuitive claim: vibe coders depend on SaaS more than big companies do, and survive its betrayal less. Big companies have platform teams, procurement leverage with backup vendors, and lawyers who read every SLA line by line. You have none of that. You use Auth0 for login not because it's the best, but because you don't have time to write OAuth yourself; you use Stripe not because the fees are optimal, but because you can collect money in three days. That trade — buying time with money — is fine. The mistake is that most people sign the deal and forget about it, until the day the bill doubles.

There are four ways a SaaS vendor can hurt you, in order of frequency:

1. Price hikes: the most common, and the mildest. After Okta acquired Auth0, its 2023 pricing restructure multiplied overage rates several-fold, and plenty of indie developers watched monthly bills jump from a couple hundred dollars to several thousand. Your revenue didn't change; your costs did.
2. Free-tier shrinkage: in August 2022 Heroku announced the end of all free plans, and on November 28 the free dynos, free Postgres, and free Redis went dark. Side projects that had run on the free tier for over a decade suddenly had to pay up or move. Unmaintained projects just went black.
3. Terms and feature changes: rate limits tightened, key features moved to the enterprise tier, data retention shortened. This is the most insidious way to die — the service still exists, but your usage suddenly became "non-compliant."
4. Shutdown: the most extreme, and the cleanest. On January 28, 2016, Facebook announced it would close the Parse hosting service, gave developers a full year to migrate, and open-sourced Parse Server. A model citizen, by industry standards. Even so, countless unmaintained apps simply stopped working after January 30, 2017.

Notice what these four have in common: none of them require you to make a mistake. Your code can be flawless and your product can keep growing — the damage comes from outside your control. That's why an "escape plan" isn't pessimism; it's basic professional hygiene for independent developers. Treat dependencies like perishable ingredients, not foundations.

2. The Dependency Triage Matrix: Grade First, Plan Later

A solo team's time is its scarcest resource — you can't write a plan for every dependency. So step one is triage: write escape plans only for "critical" dependencies, review "important" ones periodically, and let "replaceable" ones be. Grade along three axes —

• Replacement cost: what it costs to switch, including the new vendor's fees, overlapping bills during a dual-run period, and the hidden cost of migrating users.
• Migration effort: how many of your hours a switch would consume. For a one-person team, hours are more expensive than money.
• Data exportability: whether you can get your data out completely, in machine-readable form. This is the litmus test of lock-in — a dependency you can't export from owns your life, not just your code.

Score each axis 1–3 (1 = low, 3 = high); the sum is your "lock-in index." Use this table to set the tier:

Lock-in index	Tier	Definition	Action
7–9	Critical	High replacement cost, long migration, hard-to-export data. Typical: primary database, auth system, payment gateway.	One-page escape plan required; re-score quarterly; keep export scripts working.
4–6	Important	Switching hurts but is survivable. Typical: object storage, email service, error tracking, CDN.	Keep a list of backup vendors; verify exportability yearly; no full plan needed.
3	Replaceable	Standard protocols, stateless, swappable anytime. Typical: DNS, pure static hosting, one-off utility libraries.	No plan. Just prefer standard protocols at selection time.

An example to calibrate your judgment. Say your app runs on Supabase (Postgres + Auth + Storage in one): replacement cost 3 (migrating a large dataset is grunt work), migration effort 3 (RLS policies and Edge Functions must be rewritten), data exportability 1 (Postgres is Postgres — pg_dump gets everything out). Total 7: critical — but note its exportability is a perfect score, and that's exactly why it's worth using. Contrast a no-code backend where data can only be scraped out page by page through its own API, with no bulk export: replacement cost 3, migration effort 3, exportability 3 — total 9. Don't touch that kind of dependency even if it's free, because what it locks isn't your code, it's your data.

One judgment call to stress here: grade by "how much it hurts when they betray you," not "how good the service is." Good and safe are different things. The classic vibe-coder selection mistake is confusing "fast to integrate" with "low risk." The faster the integration, the deeper the coupling tends to be — and the harder it hurts.

3. The One-Page Escape Plan Template for Critical Dependencies

One page per critical dependency, stored in your project docs (Notion, README, anywhere — the key is that you can find it). Fill in this template:

Field	What to write	Example (email service)
Dependency / role	One sentence on where it sits in your architecture	Resend: signup verification, password resets, order notifications
Lock-in index & rationale	Scores on the three axes plus one line of reasoning	5 (borderline critical): sending-domain reputation is banked with them; switching providers means re-warming domains
Data / asset inventory	What of yours is in their hands	Email templates, suppression lists, sending stats, DKIM/SPF domain configs
Export method	Exactly how to get it out — commands or screenshot paths	Templates versioned in /emails in the repo; suppression list exported to CSV monthly, archived on the 1st
Backups (2)	Alternatives you can name right now, with estimated migration effort	A. AWS SES (~4h: swap SMTP config + re-verify domains); B. Postmark (~3h)
Trigger conditions	When migration starts — don't wait for the fire	Price hike over 50%, free quota halved, two outages over 4h in a row, acquisition
Migration steps (≤10)	An ops checklist written for your future self	1. Open account with backup, verify domain → 2. Import suppression list → 3. Canary 10% of traffic → … → 10. Decommission old service
Last drill date	Leave it blank if you haven't — be honest	2026-04-12 (export script verified only, no live cutover)

Note the most vicious line in the template: "trigger conditions." Most failed migrations don't fail on technology — they fail on hesitation: "let's wait and see," "maybe it's temporary," "migration is such a hassle." Writing trigger conditions in advance takes the decision out of your emotions' hands and puts it under rules on paper. Price up 50%, you leave. No discussion, no meetings, no agonizing. A solo team has no meetings — just you and your procrastination, and rules are the only thing that beat it.

Another easily missed field is implicit assets in the inventory: sender-domain reputation, OAuth apps' review status on each platform, the payment gateway's risk whitelist, CDN cache warming. These don't live in a database, can't be exported, and can only be rebuilt. List them in the plan, or you'll underestimate migration effort by at least half.

4. The 10 Anti-Lock-in Questions for Vendor Selection

The best escape plan is one that makes you hard to lock in from day one. Run through these ten questions before adopting any new dependency. If you can't answer one, score it at the worst case by default:

1. Can I export my data completely? Is there an official bulk export (not a paginated-API scraper)? Is the format open (CSV, SQL, JSON)?
2. Are there open-standard alternatives? Does it speak Postgres / S3-compatible / SMTP / OAuth — or a proprietary API it invented? Standard protocols mean the whole ecosystem is your backup.
3. Where is the free/paid boundary? Is the boundary drawn on usage or on features? Has that boundary historically widened or narrowed? (Heroku's lesson: the free tier is a gift, not a right.)
4. What does the second pricing tier cost? Don't just look at free and tier one. Model the bill at 10× users and check whether the curve is linear or a staircase — stair-step pricing is an indie developer's graveyard.
5. How does this company make money? If it mostly survives on funding and its main business has nothing to do with the product line you use (e.g., a big tech "strategic free product"), it can be cut anytime. Parse died of "strategy adjustment."
6. What happens if it gets acquired? Check its funding history and acquisition rumors. Post-acquisition price hikes and term changes are the standard script (see Auth0's pricing changes under Okta).
7. Does its status page history look healthy? Open the status page, check incident count and duration over the past year. While you're there, confirm there's a public SLA with compensation terms.
8. Has anyone in the community successfully migrated away? Search "migrate from X to Y." If you find zero migration stories, either nobody uses it or everyone who left died trying — both are terrifying.
9. How many places is my code coupled to it? Did you wrap it in an adapter? If its SDK calls are scattered across 40 files, triple your migration estimate. AI-generated code is especially prone to this "sprinkled everywhere" coupling — converge it after generating.
10. In the worst case, how much time do I get? What notice period does its terms of service promise for shutdowns or major changes? 30 days may not be enough for a solo team; 90 days is decent. Write it into your trigger conditions.

Question 9 is the vibe coder's bespoke trap. The faster AI generates code, the faster you casually import third-party SDKs everywhere. A week later you can't even remember where its API is called. My advice is a hard rule: every critical dependency gets wrapped in your own module (e.g. lib/email.ts, lib/auth.ts) — all business code talks only to your layer. When migration day comes, you rewrite one file instead of find-and-replacing across the codebase. That rule costs 10 minutes and halves migration effort.

5. Real-World Blowups, Dissected

Case 1: Parse shutdown (2016–2017) — even a "model breakup" left casualties

Facebook acquired mobile-backend platform Parse for $85 million in 2013; by 2014 it reportedly powered 500,000 apps. On January 28, 2016, Facebook announced the Parse hosting service would close, with services finally going dark on January 28, 2017 (extended in practice to January 30). As compensation, Facebook open-sourced Parse Server (a Node.js implementation) and shipped a database migration tool: developers could move data to any MongoDB and keep running on self-hosted Parse Server with barely any client-side changes.

This was a textbook graceful exit: a full year's notice + an open-source replacement + official migration tooling. And still the outcome was brutal — hordes of unmaintained legacy apps were never migrated and died on shutdown day. Three lessons: first, a migration window only matters for projects that are still alive — ten years wouldn't help an abandoned app; second, Parse could afford to be graceful because its data layer was MongoDB (standard technology) — you can only be graceful about what can actually be exported, and a vendor whose data is trapped in proprietary formats can't be graceful even if it wants to; third, don't treat "big-tech backing" as a safety net — Facebook shut down its own child without blinking, and your vendor has no too-big-to-fail exemption.

Case 2: Heroku kills the free tier (2022) — the anti-textbook of boiling frogs

On August 25, 2022, Salesforce-owned Heroku announced the end of all free plans — free dynos, free Postgres, free Redis — going dark November 28, with inactive accounts deleted starting October 26. The official reason: fighting fraud and abuse was consuming an "extraordinary amount" of the team's effort. A PaaS that had been free for over a decade suddenly started at $7/month per dyno.

This incident's damage came from the fact that there was no "migration," only "cutoff." Parse at least offered a replacement; Heroku offered a bill. Countless side projects, teaching demos, and open-source live demos on the free tier had to pay up or relocate to Render, Railway, or Fly.io within three months. The lucky ones who moved shared one trait: their apps were standard (Dockerfile / Procfile / Postgres) — switching platforms just meant switching runways. The ones that couldn't move had wired themselves deep into Heroku's add-on ecosystem with platform-specific configs.

The takeaway for solo teams is blunt: never run production traffic on a "free tier," even while it's free. Free tiers are customer-acquisition tools, not charity. Your escape plan should carry one iron rule: any dependency serving real users must run on a paid tier — only paying customers get SLAs, notice periods, and negotiating standing. The people hurt worst by Heroku weren't those paying an extra $7; they were the ones who hadn't even realized they were "running production on free Postgres."

Case 3: Auth0 repricing (2023) — price hikes are more common than shutdowns

On November 1, 2023, Okta-owned Auth0 rolled out a new pricing structure: B2C Essentials starting at $35/month for 500 MAUs, with overages at $0.07 per MAU — roughly triple the previous $0.023 rate. One developer publicly reported a bill jumping from $240 to $3,729 a month on only 1.67× user growth. Auth is one of the hardest critical dependencies to migrate: switching identity providers means moving every user session, password hashes (which can't be exported as plaintext — you migrate progressively, switching users over transparently at their next login), and OAuth app configurations for social logins.

This case shows why auth must be tiered "critical" with a plan written in advance. The nastiest line in Auth0's lock-in index isn't price — it's that password hashes can't be exported. That's a necessary consequence of good security design (a good IdP should never let you export passwords), but it also means migration is inevitably a dirty "dual-run + progressive" job. If you'd wrapped auth behind standard protocols (OIDC) from day one, migration is swapping an issuer URL; if your business logic is smeared across Auth0 Rules/Actions, migration means rewriting half your login system. Auth0's Rules stop executing entirely in November 2026 — even people who never switched vendors are being forced through a code migration.

6. SOP: Turning Plans into Muscle Memory

A plan you never rehearse is a plan you don't have. A solo team's drill doesn't need chaos engineering — three moves, once a year:

1. Export drill: for each critical dependency, actually run the export flow — confirm the file opens, row counts match, and the restore script runs. The people who survived Parse were the ones who could pg_dump on any given day.
2. Backup account setup: open a free account with each critical dependency's backup option and run the minimal loop (send a test email, store a test record). On real migration day, the last thing you want is "register an account and wait for approval." Stripe backup onboarding can involve business verification — measure that lead time in months, not days.
3. Dependency inventory review: open package.json, your env vars, your DNS records, and find the dependencies you're "using but forgot about" — then re-score and re-tier them. Vibe-coded projects accumulate dependencies frighteningly fast; skip a year of cleanup and the inventory no longer matches reality.

Plus one standing discipline: fill in a new dependency's one-pager before writing code against it. Not after. Writing code takes 10 minutes; filling one page takes 10 minutes — but the latter decides whether the former becomes a 100-hour migration hell later. Put it in your dev checklist, on the same line as "write tests."

Conclusion: The Opposite of Lock-in Isn't Building Everything Yourself — It's Having a Choice

If you've read this far, you might draw the wrong conclusion: to avoid lock-in, build everything yourself. That's a different disaster — a solo team building every wheel from scratch dies faster than one killed by a SaaS price hike. The real goal isn't "zero dependencies"; it's "every dependency has a Plan B."

Look at it another way: an escape plan's greatest value isn't even the escape. It forces you, on day one of selection, to answer three questions — where is my data, how long would a handoff take, under what conditions would I leave. People who answer those three pick loosely-coupled architectures by nature. And loosely-coupled architectures don't just defend against vendors; they defend against your own code rotting.

So stop treating "how many SaaS products I use" as the opposite of tech debt. Count the critical dependencies in your architecture, and write the first one-page escape plan tonight. Parse's users had a year to prepare, Heroku's had three months, Auth0's repricing victims got a single email — next time, you may not get off this gracefully.