Vendor-Lock-in bei Low-Code

Die Fragen, die Sie jedem Anbieter stellen sollten, uns eingeschlossen.

Fast jeder Low-Code-Anbieter wirbt damit, kein Lock-in zu erzeugen. Das ist bemerkenswert, denn bei den meisten ist die proprietäre Laufzeitumgebung das Produkt. Der Widerspruch löst sich auf, wenn man näher hinsieht: „Kein Lock-in“ bezieht sich meist auf die Daten. Über die Anwendung sagt es nichts.

Wo Lock-in tatsächlich entsteht

Ihre Daten bekommen Sie fast immer heraus, als CSV, per Schnittstelle, notfalls aus der Datenbank. Das Problem ist nie die Tabelle, sondern alles, was darum herum gebaut wurde: die Formulare, die Prüfregeln, die Workflows, die Rechte, die Auswertungen. Diese Logik ist bei plattformgebundenen Systemen kein Programm, sondern eine Konfiguration, die nur die Plattform ausführen kann.

Der Wechsel ist deshalb kein Datenumzug, sondern ein Neubau zu heutigen Preisen, während der Betrieb weiterlaufen muss. Diese Rechnung hält Unternehmen bei Plattformen, mit denen sie längst unzufrieden sind.

Was jeder Anbieter schriftlich beantworten sollte

Nicht im Vertriebsgespräch, sondern als Anlage zum Angebot. Vor allem bei Frage 2 und 7 gilt: Was nicht schriftlich vorliegt, hilft Ihnen im Ernstfall nicht.

Läuft die Anwendung nach Vertragsende weiter, und wie lange?

Die wichtigste Frage überhaupt. Lautet die Antwort „bis zum Ende der Laufzeit“, mieten Sie ein Produkt und besitzen keines.

Was genau bekommen wir beim Export, und läuft es ohne Sie?

Verlangen Sie eine Demonstration, keine Zusage: Export ziehen, auf einem fremden Server starten. Ein Export, der wieder die Plattform braucht, ist kein Export.

In welcher Sprache und mit welchen Bibliotheken ist der erzeugte Code geschrieben?

Standardtechnologien bedeuten, dass Sie auf dem Arbeitsmarkt jemanden finden. Eine herstellereigene Skriptsprache bedeutet das Gegenteil.

Wie entwickelt sich der Preis bei 50, 200 und 500 Nutzern?

Bei Lizenzmodellen pro Nutzer und Monat wächst die Rechnung mit dem Erfolg. Lassen Sie sich alle drei Stufen rechnen, und fragen Sie nach den bisherigen Preiserhöhungen bei Vertragsverlängerung.

Welche Funktionen fehlen im selbst gehosteten Betrieb?

Bei Open-Core-Anbietern liegen Anmeldung per SSO, feingranulare Rechte und Audit-Logs regelmäßig in der kostenpflichtigen Ausbaustufe, auch wenn Sie selbst hosten.

Wem gehören die Daten, und in welchem Format bekommen wir sie?

Ein Datenexport in CSV ist das Minimum. Interessant wird es bei Anhängen, Historien und Berechtigungen, denn die fehlen in Exporten am häufigsten.

Was kostet der Ausstieg?

Nicht der Vertrag, sondern der Aufwand. Wenn die Antwort „vollständiger Neubau“ lautet, kennen Sie den Preis Ihrer Abhängigkeit.

Stellen Sie diese Fragen auch uns. Hier stehen unsere Antworten, in derselben Reihenfolge.

Nach Vertragsende: läuft weiter, unbegrenzt. Es liegt keine Laufzeitlizenz darüber, die etwas abschalten könnte.
Der Export: das vollständige Projekt in Ihrem Git-Repository. Wir führen es auf einem Server vor, auf dem keine Lizenz von uns läuft.
Sprache und Bibliotheken: TypeScript mit Angular und NestJS. Keine herstellereigene Sprache.
Preis bei 50, 200, 500 Nutzern: unverändert. Es fällt keine Lizenz pro Kopf an, Wachstum ist eine Frage der Serverkapazität.
Im selbst gehosteten Betrieb: fehlt an der Anwendung nichts. Anmeldung, wahlweise gegen Ihr Verzeichnis, und feingranulare Rechte sind darin; die Protokollierung wird je Anwendung eingerichtet.
Die Daten: liegen in Ihrer Datenbank, samt Anhängen, Historien und Berechtigungen.
Der Ausstieg: kostet nichts. Das Nutzungsrecht ist unbefristet, die Anwendung läuft mit dem Stand weiter, der bei Ihnen produktiv ist. Was endet, ist die Pflege: neue Hauptversionen und Weiterentwicklung. Wie frei Ihr Team danach ist, hat sich am Projektanfang entschieden: mit Core gehören die Basisbibliotheken samt Quellcode Ihnen, mit Enterprise nicht.

Die Formen, die selten so genannt werden

Runtime-Lock-in

Die Anwendung läuft nur auf der Plattform des Anbieters. Endet die Lizenz, endet die Anwendung. Verbreitetste Form bei klassischen Enterprise-Low-Code-Plattformen.

Preis-Lock-in

Der Wechsel wäre technisch möglich, rechnet sich aber nie. Typisch bei Lizenzen pro Nutzer und Monat: Je erfolgreicher die Anwendung, desto teurer, und desto teurer auch der Ausstieg.

Wissens-Lock-in

Der Code gehört Ihnen, aber niemand außer dem Erbauer versteht ihn. Diese Form trifft Individualsoftware genauso wie Low-Code und wird am häufigsten übersehen.

Was Generierung dagegen ausrichtet

Gegen Runtime-Lock-in, weil am Ende kein Plattformartefakt steht, sondern ein Angular-/NestJS-Projekt in Ihrem Repository. Es läuft auf jeder Container-Plattform, weil es nichts kennt außer den üblichen Bausteinen.

Gegen Preis-Lock-in, weil keine Laufzeitlizenz pro Kopf anfällt. Ob zehn oder fünfhundert Menschen mit der Anwendung arbeiten, ist eine Frage Ihrer Serverkapazität.

Gegen Wissens-Lock-in, den unterschätzten Teil, weil jede generierte Anwendung derselben Struktur folgt. Wer eine kennt, findet sich in der nächsten zurecht. Handgeschriebene Individualsoftware erreicht dieselbe Einheitlichkeit nur über Konventionen, die jemand über Jahre durchsetzt; bei generierten Anwendungen bringt sie der SOLUTIONS.designer mit.

Was ehrlicherweise bei uns bleibt

Eine Anwendung besteht aus drei Teilen. Ihre Anwendung geht mit Quellcode an Sie über. Die Basisbibliotheken gibt es in zwei Fassungen: Core mit Quellcode, Enterprise ohne, dafür im vorhandenen Stand weiter nutzbar. Enterprise ist damit eine Bindung an uns, und wir nennen sie so; die Wahl gehört an den Projektanfang. Unsere eigenen Dienste brauchen ein eigenes Nutzungsrecht: SOLUTIONS.transformer, .connect_LDAP, .dashboard, .file, .email, .mcp, .translate, .admin. Der vollständige Schnitt steht unter Lizenzmodell und Quellcode.

Die zweite Ehrlichkeit: Sobald von Hand weiterentwickelt wird, erzeugen wir die Anwendung nicht mehr neu, sonst wären Ihre Anpassungen weg. Ab da ist es normale Softwareentwicklung, und der SOLUTIONS.designer hält Sie an nichts fest.

Weiterlesen

Häufige Fragen

Was bedeutet Vendor-Lock-in bei Low-Code konkret?

Dass die Anwendung nur läuft, solange Sie den Anbieter bezahlen. Ursache ist fast immer die proprietäre Laufzeitumgebung: Die visuell konfigurierte Logik ist kein eigenständiges Programm, sondern eine Konfiguration, die nur die Plattform des Anbieters ausführen kann.

Reicht ein Code-Export, um Lock-in zu vermeiden?

Nur wenn der exportierte Code ohne die Plattform lauffähig und für Ihr Team lesbar ist. Manche Anbieter exportieren eine Beschreibung des Modells, kein eigenständiges Projekt. Die praktische Prüfung: Kann Ihr Team den Export auf einem beliebigen Server starten, ohne den Anbieter zu kontaktieren?

Wie erkenne ich Lock-in schon im Angebot?

An drei Stellen: einem Preismodell pro Nutzer und Monat ohne Obergrenze, dem Fehlen einer klaren Aussage zum Verbleib nach Vertragsende und der Kombination aus „unbegrenzt anpassbar“ und einer eigenen Skriptsprache, die es nur bei diesem Anbieter gibt.

Gibt es Lock-in auch bei einer Individualsoftware-Agentur?

Ja, nur trägt er dort keinen Produktnamen. Wenn Struktur und Konventionen von Projekt zu Projekt verschieden sind und die Kenntnis über den Code in wenigen Köpfen liegt, sind Sie an diese Personen gebunden, unabhängig davon, wem der Code juristisch gehört.

Wie verhindert Prompt Your App das?

Der SOLUTIONS.designer erzeugt ein gewöhnliches Angular-/NestJS-Projekt in Ihrem Git-Repository, das auf jeder Container-Plattform läuft. Keine Laufzeitlizenz kann es abschalten. Die Basisbibliotheken gehen in der Fassung Core mit Quellcode an Sie über, unbefristet und änderbar. Ein eigenes Nutzungsrecht brauchen unsere Dienste, etwa SOLUTIONS.transformer; die laufen nach Vertragsende im vorhandenen Stand weiter.

Ist die Fassung Enterprise dann nicht selbst ein Lock-in?

Im Kern ja, und wir sagen es lieber selbst. Enterprise geht ohne Quellcode an Sie, an den Basisbibliotheken kann Ihr Team also nichts ändern. Zwei Dinge begrenzen das: Es schaltet sich nichts ab, die Anwendung läuft mit dem Stand weiter, den Sie haben. Neue Funktionen und Hauptversionen hängen dagegen an einer laufenden Pflege. Und Ihre eigene Anwendung ist davon nicht berührt, die gehört Ihnen mit Quellcode. Wer diese Bindung gar nicht will, baut auf Core, das mit Quellcode übergeht und dafür weniger mitbringt. Weil der nachträgliche Wechsel ein Umbau ist, fragen wir vor dem ersten Entwurf danach. Der vollständige Schnitt steht unter Lizenzmodell und Quellcode.