What lock-in really costs a solo founder

Lock-in is not a contract clause you sign away. It is the slow accumulation of decisions that, taken together, make leaving a vendor more expensive than staying — even when the vendor raises prices, ships a worse product, or sunsets the feature you depend on. For a solo founder, the cost shows up as weeks of unpaid migration work, lost customer data, broken integrations, and a support queue that nobody answers while you rebuild.

This article gives you a checklist you can run on any cloud, SaaS, or AI tool before you commit — and a simple way to estimate what leaving would actually cost you.

The four lock-in vectors worth checking

Almost every lock-in situation comes from one of four vectors. Score each from 0 (none) to 3 (severe) for every tool you evaluate.

  1. Proprietary API and runtime lock-in. Code or configuration that only runs on one provider — a serverless function tied to a vendor-specific event shape, a database query that uses a proprietary extension, an IAM model wired through one cloud’s SDKs. The shorter and more standard the interface, the safer you are.
  2. Format and data lock-in. Egress fees, non-portable exports, vendor-only snapshot formats, or “standard” formats with proprietary extensions layered on top. Ask whether a normal Postgres dump, CSV export, or JSON file would actually let you move.
  3. Operational lock-in. Your runbooks, IaC modules, CI pipelines, dashboards, and on-call habits built around one ecosystem. This is the form founders underestimate most, because it lives in muscle memory rather than code.
  4. Contractual and commercial lock-in. Bundled discounts that collapse if you drop one product, auto-renewing terms, exit penalties, and pricing that is generous at low volume but punitive at scale.

A tool that scores 0–4 across all four is a comfortable choice. 5–8 means you should negotiate an exit path before signing. 9 or above is a structural dependency — budget for migration from day one.

The 15-minute pre-signup checklist

Run these questions against every serious candidate. Treat “I don’t know” as a failing answer.

Data and exports

  • Can I export my full dataset, including history and audit trail, in a documented open format?
  • Is the export automated through an API, or only a manual ticket?
  • Are there per-record or per-GB egress fees I have to budget for?
  • If I stop paying, how long do I keep read access to my data?

APIs and integration

  • Is the public API documented, versioned, and stable across years?
  • Can I point a competing tool at the same data source, or do I have to rebuild the integration?
  • Are webhooks, event streams, and identity providers (OIDC, SAML) standards-based?

Operational footprint

  • Can I reproduce my setup from a script, or is it a UI you clicked through?
  • Are dashboards, logs, and alerts exportable, or trapped in the vendor’s UI?
  • How much of my team’s knowledge is “where to click” versus “what to write”?

Contract terms

  • What happens to my data on termination, and on what timeline?
  • Are there auto-renewals, minimum terms, or bundled discounts I lose by dropping a product?
  • Is pricing public, and does it scale linearly with usage, or step up at thresholds?

If you cannot answer at least 10 of these from the vendor’s website and contract, you do not yet have enough information to choose.

A simple switching-cost framework

Before signing, write a one-page exit plan. It does not need to be detailed, but it forces clarity. Use this template:

  1. What data would I have to move, and in what format? (rows, GB, schema quirks)
  2. What code or configuration would I have to rewrite? (estimated hours, not vibes)
  3. What integrations would break, and how do I rebuild them? (named dependencies, not categories)
  4. What is the downtime or degraded-service window customers would see?
  5. What would the migration cost in dollars, assuming my time is worth something?

If you cannot fill this in one page, the lock-in is heavier than the vendor’s marketing lets on. One ITAM-style test worth borrowing from enterprise practice: if your team cannot describe the exit on a single page, including what you would lose, what it would cost, and how long it would take, you do not have enough information to negotiate confidently — let alone to sign a multi-year commit.

Reversible vs. restrictive lock-in — know which you are in

Not all dependencies are equal. Reversible lock-in means you can leave with planning: data is exportable in a usable format, integrations can be rebuilt with reasonable effort, and the cost of leaving is mostly internal time. Restrictive lock-in means exports are unavailable or prohibitively expensive, contract terms make leaving commercially irrational, or the product is embedded deeply enough that replacement carries real service risk.

The difference between the two is usually measured in months versus years of switching effort. Most solo founders will never migrate a restrictive lock-in — they will just keep paying. So the goal at signup is to make sure every tool you adopt sits firmly in the reversible column.

Deliberate, accidental, or mutual: who created the dependency?

Lock-in is not always engineered by the vendor. Sometimes it is accidental — your team built custom logic on a proprietary feature because it was fastest at the time. Sometimes it is mutual — both sides invested in an integration that would be painful to replace. Understanding who created the dependency changes how you respond. Deliberate lock-in is a contract negotiation. Accidental lock-in is an architecture cleanup. Mutual lock-in is a relationship to manage, not a problem to flee.

Practical patterns that keep you swappable

You do not need to avoid every proprietary service to stay safe. You need to keep the blast radius small.

  • Wrap every vendor in an internal interface. A thin module in your codebase that owns all calls to a single provider. When you swap vendors, you rewrite one file, not the whole app.
  • Match tools to components, not trends. One tool per job. Retrieval retrieves. Email sends email. Hosting hosts. Sprawl creates the weeds that strangle you later.
  • Prefer standard formats over vendor extensions. Standard Postgres over a managed fork with proprietary types. Standard CSV exports over custom JSON dialects. You can always move up later; you cannot always move down.
  • Keep an exportable backup of your most important data, on a schedule you control. Even if the vendor offers exports, having your own copy changes the negotiation.
  • Score tools by architecture, not hype. Modularity, auditability, and swap-ability matter more than demo-day polish.

When lock-in is the right answer

Sometimes the bet is worth making. A proprietary database that lets you ship a feature six months earlier, a managed AI service that saves you a quarter of ML engineering, a low-code platform that lets one founder run an entire product — these are legitimate trades. The mistake is making them without knowing the price.

If you decide to accept lock-in, write that decision down. Name the vendor, the dependency you are accepting, the trigger that would make you leave (price increase, sunset notice, security incident), and the rough cost of leaving. A one-paragraph memo, filed next to the contract, beats a year of regret.

FAQ

What is the single best question to ask a SaaS vendor about lock-in? “If I cancel tomorrow, in what format, and on what timeline, do I get my data back?” If the answer is vague, you have your answer.

Are open-source tools always safer from lock-in? No. Self-hosting shifts lock-in from the vendor to you — your team’s operational knowledge, your migration scripts, your upgrade path. Open source removes commercial lock-in but does not remove technical or operational lock-in on its own.

How often should I review lock-in risk? Every renewal, and every time a tool crosses a usage threshold that changes your switching cost. Once a year at minimum.

What is the most common lock-in founders underestimate? Operational lock-in — the dashboards, runbooks, and habits built around one ecosystem. It feels free until the day you have to leave.

Sources