Der neue Vendor Lock-in: APIs statt Abos

Abomodelle kann man kündigen. Man exportiert die Daten, wechselt den Anbieter, zahlt ab nächstem Monat woanders. Unangenehm, aber machbar. Die neue Generation von Abhängigkeiten funktioniert anders: Sie wächst still in den Code, in die Datenstrukturen, in die Infrastruktur hinein — und macht Wechsel nicht unmöglich, aber so teuer, dass sie in der Praxis nicht stattfinden.

Wenn du heute nicht innerhalb von 30 Tagen von einem kritischen Anbieter wegkommst, bist du bereits im Lock-in.

Wie der neue Lock-in entsteht

Der klassische Lock-in war sichtbar: Oracle-Datenbanken, SAP-Implementierungen, Microsoft-Formate. Unternehmen wussten, wenn sie sich banden. Die Entscheidung war bewusst.

Heute entsteht Abhängigkeit durch technische Integration, nicht durch Lizenzverträge. Drei Mechanismen sind dabei besonders wirksam:

API-Tiefenintegration: Eine REST-API ist zunächst harmlos. Aber je tiefer sie in Workflows, Datenmodelle und Geschäftslogik integriert wird, desto größer werden die Wechselkosten. Stripe ist ein Lehrbeispiel: Die API ist exzellent, die Preise fair. Wer Stripe tief integriert hat — Webhooks, Subscriptions, Billing-Portale, Steuerlogik — hat Monate Arbeit investiert, die bei einem Wechsel komplett neu geschrieben werden muss. Nicht wegen proprietärer Formate, sondern wegen anbieter-spezifischer Konzepte.

Datenformat-Lock-in: SaaS-Tools speichern Daten in eigenen Strukturen. Notion-Blocks, Airtable-Schemas, Salesforce-Objekte. Die meisten Anbieter bieten Export — aber ein Export ist kein gleichwertiger Ersatz. Relationen gehen verloren, Metadaten fehlen, Automatisierungen müssen neu aufgebaut werden.

KI-Modell-Abhängigkeit: Wer Monate damit verbracht hat, Prompts für ein spezifisches Modell zu optimieren, hat Know-how aufgebaut, das nicht übertragbar ist. GPT-4o und Claude reagieren auf dieselben Prompts unterschiedlich. Fine-Tuning auf eigenen Daten schafft den härtesten Lock-in überhaupt: Training, Datenaufbereitung und Evaluation müssen komplett neu durchgeführt werden — bei einem anderen Anbieter.

Der eigentliche Mechanismus: Lock-in entsteht nicht durch eine große Entscheidung, sondern durch hundert kleine, jeweils vernünftige Entscheidungen.

Den eigenen Stack bewerten: Lock-in Score

Bevor man handelt, muss man wissen, wo man steht. Bewerte jeden kritischen externen Service:

Faktor	Frage	1–5
Tiefe Integration	Wie viele Core-Flows hängen daran?
Datenbindung	Liegen kritische Daten nur dort?
Wechselkosten	Wie lange würde ein Ersatz dauern?
Alternativen	Gibt es realistische Alternativen? (5 = keine)

Score:

• 4–8 → unkritisch, beobachten
• 9–14 → aktiver Lock-in, Strategie entwickeln
• 15–20 → kritische Abhängigkeit, sofort adressieren

Mach das für Stripe, AWS, dein CMS, dein LLM, dein Analytics-Tool. Das Ergebnis zeigt, wo die echten Risiken liegen — nicht wo man es vermutet.

So baust du es besser: konkrete Patterns

API-Lock-in entschärfen

Das häufigste Problem: SDKs werden direkt überall im Code verwendet.

// Typisch — direkt Stripe im Business-Code
const subscription = await stripe.subscriptions.create({
  customer: stripeCustomerId,
  items: [{ price: stripePriceId }],
});

Wenn Stripe die Preise erhöht oder die API bricht, muss der gesamte Business-Code angefasst werden.

// Besser — eigene Abstraktion
interface BillingProvider {
  createSubscription(params: {
    userId: string;
    plan: 'starter' | 'pro' | 'enterprise';
  }): Promise<Subscription>;
}

// Stripe-Adapter implementiert das Interface
class StripeAdapter implements BillingProvider {
  async createSubscription({ userId, plan }) {
    // Stripe-spezifischer Code hier
  }
}

// Business-Code arbeitet nur gegen das Interface
const billing = getBillingProvider(); // gibt StripeAdapter zurück
await billing.createSubscription({ userId, plan: 'pro' });

Effekt: Anbieterwechsel = Adapter austauschen. Business-Logik bleibt stabil. Der Aufwand für den Wechsel sinkt von Monaten auf Wochen.

Daten nicht im SaaS-Tool einschließen

// Don't: Notion als einzige Quelle für Kunden-Dokumentation
const docs = await notion.databases.query({ database_id: DB_ID });

// Do: Regelmäßiger Export als Backup + eigenes Read-Model
// cron: täglich
async function syncNotionToLocalDB() {
  const pages = await notion.databases.query({ database_id: DB_ID });
  await db.upsertMany('knowledge_base', pages.results.map(mapNotionPage));
}

// Anwendung liest aus eigenem Modell, nicht direkt Notion
const docs = await db.query('SELECT * FROM knowledge_base WHERE ...');

Effekt: Notion kann abgeschaltet, ersetzt oder migriert werden — die Anwendung läuft weiter.

LLM-Abhängigkeit begrenzen

// Don't: Direkt auf ein Modell optimiert, hardgecodete Prompts
const response = await openai.chat.completions.create({
  model: 'gpt-4o',
  messages: [{ role: 'user', content: hardcodedPrompt }],
});

// Do: Abstraktionsschicht + versionierte Prompts
import { loadPrompt } from '@/prompts'; // JSON aus Git, versioniert
import { getLLMProvider } from '@/llm';  // konfigurierbar per ENV

const provider = getLLMProvider(); // openai, anthropic, ollama — austauschbar
const prompt = loadPrompt('summarize', { version: 'v2' });

const response = await provider.complete({ prompt, input });

// Output validieren — nicht blind vertrauen
const validated = SummarySchema.parse(response); // zod o.ä.

Effekt: Modellwechsel ohne Code-Änderung. Prompts sind in Git versioniert und nachvollziehbar. Ausgaben sind validiert.

Do / Don’t

APIs

Don’t:

• SDKs direkt überall im Business-Code verwenden
• Business-Logik an API-Response-Strukturen koppeln
• Anbieter-spezifische IDs (z.B. stripeCustomerId) direkt im Domain-Modell speichern

Do:

• Adapter/Wrapper für jeden kritischen externen Service schreiben
• Eigene interne Datenmodelle definieren, Mapping in der Infrastrukturschicht
• Abhängigkeiten in einer Datei/Modul konzentrieren, nicht verteilen

SaaS / Daten

Don’t:

• Tool als einzige „Source of Truth” ohne Exportstrategie
• Kritische Daten nur im SaaS-Tool, ohne lokale Kopie

Do:

• Regelmäßige Exporte automatisieren (täglich, nicht manuell)
• Daten zusätzlich in eigenem System halten (Read-Model oder Backup-DB)
• Exportformat vorab prüfen: CSV ist kein vollständiger Export

KI / LLMs

Don’t:

• Prompts hardcoden und nie versionieren
• Direkt auf ein einzelnes Modell optimieren ohne Alternative
• Fine-Tuning ohne Exit-Plan starten

Do:

• Prompts als JSON-Dateien in Git versionieren
• Outputs gegen ein Schema validieren (Zod, Pydantic, JSON Schema)
• Mindestens zwei Modelle testbar halten (z.B. Claude + GPT-4o)
• Abstraktionsschicht verwenden: LiteLLM, eigener Provider-Wrapper

Migration vorbereiten, bevor man sie braucht

Das ist der Teil, der am meisten Mehrwert bringt — und am wenigsten gemacht wird.

Wenn ein Anbieter die Preise erhöht, abgeschaltet wird oder ein besseres Angebot auftaucht, entscheidet nicht die technische Möglichkeit, sondern die Vorbereitung, wie schnell ein Wechsel machbar ist. Drei konkrete Maßnahmen:

Alle externen Calls zentralisieren. Wenn Stripe an 40 Stellen im Code aufgerufen wird, ist Migration schwer. Wenn alle Stripe-Calls in einem BillingService oder StripeAdapter liegen, ist Migration eine Frage von Tagen. Das lohnt sich auch ohne Lock-in-Absicht — es macht den Code besser.

Shadow-Provider testen. Für kritische Services kann man 5–10% des Traffics parallel über eine Alternative laufen lassen, bevor man sich festlegt. Das zeigt, ob die Alternative tatsächlich hält, was sie verspricht — ohne Produktionsrisiko. Bei LLMs besonders relevant: Prompt-Kompatibilität zeigt sich nur im echten Betrieb.

Exit-Kriterien definieren, bevor man einsteigt. Bevor ein neuer Anbieter integriert wird: Unter welchen Bedingungen würde man wechseln? Preiserhöhung über X%? Downtime über Y Stunden im Monat? Vendor Exit? Wer diese Fragen vorab beantwortet, hat einen klaren Handlungsrahmen — statt im Ernstfall unter Druck zu entscheiden.

Realistische Trade-offs

Der Artikel wäre unehrlich, würde er den Lock-in nur als Problem darstellen.

Stripe mit Lock-in ist oft besser als eine eigene Billing-Lösung ohne Lock-in. Stripe hat jahrelange Arbeit in Sicherheit, Compliance, Steuerlogik und Zuverlässigkeit investiert. Das selbst zu bauen kostet mehr — in Zeit, Risiko und Wartungsaufwand — als die Abhängigkeit.

Die Frage ist nicht: Kein Lock-in um jeden Preis. Die Frage ist: Ist der Wert, den der Anbieter liefert, den Preis der Abhängigkeit wert?

Eine nützliche Heuristik nach Wachstumsphase:

Early Stage: Bewusst Lock-in akzeptieren. Zeit ist knapper als Architekturflexibilität. Stripe, Firebase, Vercel — fertig. Kein Wrapper, kein Adapter. Schnell liefern.

Scaling: Lock-in reduzieren, wo er zu Risiko wird. Services mit Score 12+ adressieren. Abstraktionsschichten für die 2–3 kritischsten Abhängigkeiten einziehen.

Enterprise: Lock-in aktiv managen. Architektur-Reviews für neue externe Services. Regelmäßige Bewertung bestehender Abhängigkeiten. Exit-Pläne für alles mit Score 15+.

Unterm Strich

Der neue Vendor Lock-in ist subtiler als der alte — und deshalb gefährlicher. Er entsteht nicht durch einen Vertrag, sondern durch hundert vernünftige technische Entscheidungen, die sich zu einer strategischen Abhängigkeit summieren.

Mit KI-Modellen kommt eine neue Dimension dazu: Prompt-Engineering ist schwer portierbar, Fine-Tuning bindet an spezifische Anbieter, und Modell-Updates verändern Verhalten ohne Changelog.

Das ist kein Grund, APIs oder LLMs zu meiden. Es ist ein Grund, sie mit denselben Architektur-Überlegungen anzugehen wie jede andere kritische Abhängigkeit: Lock-in Score berechnen, Abstraktion einziehen, Exit-Kriterien definieren — bevor man sie braucht.