Low-Code oder individuelle Entwicklung: Entscheidung für B2B-Tools

Das Problem: Ein Tool soll her — aber auf welchem Weg?

Die Ausgangslage kenne ich aus fast jedem Erstgespräch: Ein Prozess läuft über Excel, E-Mail und Zuruf, alle wissen, dass ein internes Tool oder eine kleine Web-App das lösen würde — und dann kommt die Frage, an der Projekte monatelang hängen bleiben: Bauen wir das mit einer Low-Code-Plattform oder lassen wir individuell entwickeln?

Die Frage ist berechtigt, denn beide Wege haben reale Kosten und reale Risiken, nur an unterschiedlichen Stellen. Und sie ist dringlicher geworden: Laut Bitkom fehlen der deutschen Wirtschaft rund 109.000 IT-Fachkräfte, und eine offene IT-Stelle bleibt im Schnitt 7,7 Monate unbesetzt (Stand August 2025). Wer auf das eigene Entwicklerteam wartet, wartet oft lange — genau das macht Low-Code für Fachbereiche so attraktiv. Gleichzeitig hat KI-gestützte Entwicklung die Kosten individueller Software deutlich gesenkt, was die alte Faustregel „Custom ist immer teuer und langsam” ins Wanken bringt.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die diese Entscheidung für ein konkretes B2B-Tool treffen müssen. Er ist Teil unserer Übersicht zu KI-Softwareentwicklung, Tools und MVPs. Meine Position vorweg, damit du weißt, mit wem du es zu tun hast: Ich entwickle individuell (Web-Apps, interne Tools, MVPs) und nutze selbst Workflow-Plattformen wie n8n — ich habe also auf beiden Seiten Haut im Spiel und kein Interesse daran, dir den falschen Weg zu verkaufen. Das teuerste Ergebnis ist ein Tool auf dem falschen Fundament.

Begriffe kurz geklärt

• Low-Code: Anwendungen werden überwiegend visuell zusammengebaut — Formulare, Datenmodelle, Workflows per Drag-and-drop, ergänzt um kleine Code-Schnipsel, wo nötig. Typische Vertreter: Microsoft Power Apps/Power Automate, Mendix, OutSystems, Retool.
• No-Code: Die Zuspitzung davon: null Programmierung, reine Konfiguration. Die Grenze zu Low-Code ist fließend; in diesem Artikel behandle ich beides zusammen, weil die Entscheidungslogik dieselbe ist.
• Individuelle Entwicklung (Custom Code): Software wird mit klassischen Programmiersprachen und Frameworks gebaut — heute meist KI-unterstützt, aber mit vollem Zugriff auf Architektur, Datenhaltung und Oberfläche. Der Code gehört dir.
• Citizen Development: Fachbereichsmitarbeitende ohne Entwicklerhintergrund bauen selbst Apps auf Low-Code-Plattformen. Die OWASP führt dafür eine eigene Risikoliste — dazu unten mehr.

Wichtige Abgrenzung: Workflow-Automatisierung (n8n, Make, Power Automate) ist ein Teilgebiet von Low-Code, aber nicht dasselbe wie ein Tool mit eigener Oberfläche und Datenhaltung. Viele „Wir brauchen ein Tool”-Anfragen entpuppen sich als reine Integrationsaufgabe — die ist fast immer ein Fall für Workflow-Tools, nicht für Custom Code. Dieser Artikel behandelt den Fall, dass wirklich eine Anwendung mit Oberfläche, Nutzern und Daten entstehen soll.

Wann eignet sich Low-Code?

Low-Code spielt seine Stärke aus, wenn dein Vorhaben nah am Standard liegt. Konkret sprechen diese Merkmale dafür:

• Das Tool besteht aus bekannten Bausteinen. Formulare, Listen, Freigabe-Workflows, einfache Auswertungen, CRUD-Operationen („anlegen, lesen, ändern, löschen”) auf strukturierten Daten. Urlaubsantrag, Besucherregistrierung, Onboarding-Checkliste, Geräteverwaltung — dafür musst du nichts erfinden.
• Die anzubindenden Systeme haben fertige Konnektoren. Microsoft 365, gängige CRMs, Standard-Datenbanken. Wenn die Plattform deine Systemlandschaft von Haus aus kennt, entfällt der teuerste Teil der Integration.
• Zeit schlägt Perfektion. Eine funktionierende 80-Prozent-Lösung in zwei Wochen ist wertvoller als die perfekte Lösung in sechs Monaten — vor allem, wenn der Prozess sich ohnehin noch ändert.
• Der Fachbereich soll selbst anpassen können. Feldnamen, Workflow-Schritte, Empfängerlisten — Änderungen dieser Art ohne Entwicklungsprojekt sind ein echter Vorteil im Alltag.
• Ihr steckt schon in einem Ökosystem. Wer Microsoft 365 im Einsatz hat, bekommt mit der Power Platform viel Infrastruktur (Login, Rechte, Hosting) geschenkt, die ein Custom-Projekt erst aufbauen müsste.

Die ehrliche Einschränkung: Diese Eignung ist an den Zuschnitt des Problems gebunden, nicht an dessen Wichtigkeit. Auch ein geschäftskritischer Prozess kann perfekt zu Low-Code passen — solange er aus Standardbausteinen besteht.

Wann ist Custom Code sinnvoll?

Individuelle Entwicklung wird dann zur besseren Wahl, wenn einer dieser Punkte den Kern deines Tools ausmacht:

• Komplexe Fachlogik. Preisfindung mit Dutzenden Regeln und Ausnahmen, Planungs- und Optimierungslogik, mehrstufige Berechnungen mit Historie. Genau hier erreicht Low-Code seine Grenzen: Was sich nicht in die vorgesehenen Bausteine pressen lässt, wird zu einer Kette von Workarounds — schwer zu testen, schwer zu debuggen, und bei jeder Plattform-Änderung ein Risiko.
• Individuelle Oberfläche und Nutzererlebnis. Sobald externe Kunden oder Partner das Tool bedienen (Kundenportal, Self-Service), zählt die Oberfläche. Low-Code-Oberflächen sind funktional, aber erkennbar generisch und nur begrenzt formbar.
• Hohe Volumen und Lastspitzen. Plattformen schützen sich über Kontingente: In der Microsoft Power Platform hat z. B. ein bezahlter Nutzer 40.000 Requests pro 24 Stunden, mit Microsoft-365-Lizenzen sind es 6.000; eine einzelne Flow-Lizenz erlaubt 250.000 Requests pro Tag. Für typische interne Apps ist das großzügig — für datenintensive Verarbeitung wird die Lizenzrechnung schnell zur Architekturfrage.
• Das Tool ist Teil deines Wettbewerbsvorteils. Wenn die Software abbildet, was dein Unternehmen besser kann als andere, willst du sie besitzen, formen und weiterentwickeln können — nicht auf der Roadmap eines Plattformanbieters warten.
• Besondere Integrations-, Datenschutz- oder Compliance-Anforderungen. Eigenes Hosting, spezifische Datenhaltung, Schnittstellen zu Alt-Systemen ohne Konnektor, Audit-Anforderungen — alles machbar mit Custom Code, bei Low-Code teils gar nicht oder nur in teuren Enterprise-Stufen.

Dazu kommt ein Faktor, der die Abwägung in den letzten Jahren real verschoben hat: KI-gestützte Entwicklung macht individuelle Software schneller und günstiger als früher. Das Argument „Custom dauert sechs Monate, Low-Code zwei Wochen” stimmt so pauschal nicht mehr — ein fokussiertes internes Tool ist auch individuell in Wochen baubar. Was bleibt: Custom Code braucht jemanden, der Architektur, Qualität und Betrieb verantwortet. KI schreibt Code, aber sie trägt keine Verantwortung.

Wie unterscheiden sich Lock-in und Wartung?

Das ist der am meisten unterschätzte Teil der Entscheidung, weil er sich erst nach zwei, drei Jahren bemerkbar macht.

Low-Code heißt: Du mietest das Fundament. Das hat echte Vorteile — Sicherheitsupdates, Hosting, Skalierung und Browser-Kompatibilität pflegt der Anbieter. Aber es bindet dich dreifach:

1. Preis- und Lizenz-Lock-in. Der Anbieter kann Preismodelle, Kontingente und Enforcement ändern; deine App läuft weiter, aber die Rechnung sieht anders aus. Bei nutzerbasierten Lizenzen wächst die Rechnung zudem mit jedem Mitarbeiter, der das Tool nur gelegentlich öffnet.
2. Funktions-Lock-in. Was die Plattform nicht vorsieht, bekommst du nicht — oder nur als Workaround, der bei Plattform-Updates brechen kann.
3. Exit-Lock-in. Der entscheidende Punkt: Eine Low-Code-App ist nicht portabel. Die Daten bekommst du in der Regel heraus, die Anwendung selbst nicht — ein Plattformwechsel ist ein Neubau. Wer nach vier Jahren mit fünfzehn produktiven Apps wechseln will, baut fünfzehn Apps neu.

Custom Code heißt: Dir gehört das Haus — samt Instandhaltung. Der Code liegt in deinem Repository, du kannst Hoster, Dienstleister und Technologie wechseln. Dafür trägst du, was der Plattformanbieter sonst trägt: Abhängigkeits-Updates, Sicherheitspatches, Monitoring, Backups. Das ist kein Hexenwerk, aber es ist ein laufender Posten, der budgetiert gehören — wer ihn ignoriert, hat nach zwei Jahren eine ungewartete Anwendung mit bekannten Sicherheitslücken. Und es gibt einen Custom-spezifischen Lock-in, den viele übersehen: das Wissensmonopol. Wenn nur eine Person (oder eine Agentur ohne Dokumentationspflicht) das System versteht, bist du an sie gebunden wie an jede Plattform. Dokumentation, sauberes Repository und ein Review durch Dritte sind hier die Versicherung.

Die nüchterne Zusammenfassung: Beide Wege haben Lock-in — bei Low-Code liegt er beim Anbieter, bei Custom Code beim Wissensträger. Steuern kannst du beides, aber nur, wenn du es von Anfang an einplanst.

Welche Sicherheitsfragen zählen?

Low-Code wird oft als „sicher, weil die Plattform sich kümmert” verkauft. Das stimmt für die Infrastruktur — nicht für das, was darauf gebaut wird. Die OWASP Foundation pflegt dafür eine eigene Top-10-Liste (Citizen Development Top 10), und deren wichtigste Punkte solltest du kennen, bevor Fachbereiche Apps bauen:

• Account Impersonation: Die App läuft mit den Rechten der Person, die sie gebaut hat — im schlimmsten Fall greifen alle Endnutzer mit Admin-Rechten des Erstellers auf Daten zu.
• Authorization Misuse / fehlerhafte Berechtigungen: Wer darf in der App was sehen und ändern? In schnellen Fachbereichs-Apps wird das selten sauber durchdacht.
• Sensitive Data Leakage: Konnektoren machen es trivial, Daten zwischen Systemen zu bewegen — auch dorthin, wo sie nicht hingehören (privates Postfach, ungeschütztes SharePoint, US-Cloud-Dienst).
• Vulnerable and Untrusted Components: Fertige Bausteine und Vorlagen aus Plattform-Marktplätzen können Schwachstellen mitbringen.
• Asset Management Failures: Der Klassiker nach zwei Jahren Citizen Development: Dutzende Apps, niemand weiß mehr, welche produktiv wichtig sind und wem sie „gehören”.

Bei individueller Entwicklung gelten die klassischen Anwendungssicherheits-Themen (Injection, Authentifizierung, Abhängigkeiten) — der Unterschied ist nicht „sicher vs. unsicher”, sondern wer die Verantwortung sichtbar trägt: Bei Custom Code ist klar, dass du (bzw. dein Dienstleister) für Sicherheit zuständig bist. Bei Low-Code fühlt sich niemand zuständig, weil „die Plattform das doch macht” — genau aus dieser Lücke entstehen die OWASP-Fälle.

Ein Punkt noch, weil er beide Welten betrifft: Sowohl Citizen Developer als auch professionelle Entwickler arbeiten zunehmend mit generativer KI. Das BSI hat dazu eine eigene Publikation vorgelegt („Generative KI-Modelle — Chancen und Risiken für Industrie und Behörden”, Januar 2025), die als Grundlage für eine systematische Risikoanalyse gedacht ist — u. a. zu Halluzinationen und unsicheren Ergebnissen. Meine Kurzfassung für die Tool-Entscheidung: KI-generierte Logik gehört geprüft, egal ob sie in einem Low-Code-Baustein oder in einer Codebasis landet. (Stand Juli 2026; keine Rechtsberatung — bei personenbezogenen Daten gehören Datenschutzfragen mit den offiziellen Quellen und ggf. eurem Datenschutzbeauftragten geklärt.)

Kann man hybrid starten?

Ja — und in meiner Praxis ist das häufiger die richtige Antwort als ein reines Entweder-oder. Drei Muster funktionieren zuverlässig:

Muster 1: Low-Code außen, Custom Code im Kern. Der Prozessrahmen (Formulare, Benachrichtigungen, Freigaben) läuft auf der Plattform; die komplexe Fachlogik — Preisberechnung, Datenaufbereitung, KI-Verarbeitung — liegt in einem kleinen, eigenen Service mit API, den die Plattform aufruft. So bleibt der differenzierende Teil portabel und testbar, während der Standardteil schnell und vom Fachbereich anpassbar bleibt.

Muster 2: Low-Code als Wegwerf-Prototyp. Der Prozess wird erst auf der Plattform ausprobiert, bis klar ist, was er wirklich braucht — dann wird gezielt individuell gebaut. Das ist legitim, wenn du den Prototypen ehrlich als Wegwerf-Artefakt behandelst. Die Falle: Der „Prototyp” läuft drei Jahre produktiv, weil er ja funktioniert — und die Ablösung wird nie budgetiert.

Muster 3: Custom-App plus Workflow-Tool. Die Anwendung selbst ist individuell gebaut, aber die Integrationen drumherum (Benachrichtigungen, Datenabgleiche mit Drittsystemen) laufen über ein Workflow-Tool wie n8n. So halten wir es selbst: Eigene Produkte individuell, Automatisierung dort, wo sie am billigsten zu haben ist.

Die eine Regel, die alle drei Muster tragen: Definiere die Schnittstelle bewusst. Wenn Plattform-Teil und Custom-Teil über eine dokumentierte API sprechen, kannst du später jede Seite austauschen. Wenn die Grenze quer durch gewachsene Workarounds läuft, hast du den Lock-in beider Welten kombiniert.

Die Entscheidungsmatrix

Meine Arbeitshilfe für den KMU-Kontext — gehe die Kriterien durch und zähle ehrlich, wohin die Mehrheit zeigt. Zwei Kriterien haben Vetorecht (fett markiert): Wenn eines davon klar auf einer Seite liegt, überstimmt es den Rest.

Kriterium	Spricht für Low-Code	Spricht für individuelle Entwicklung
Komplexität der Fachlogik (Veto)	Standard-Workflows, Formulare, CRUD	Viele Regeln, Ausnahmen, Berechnungen, eigene Algorithmen
Tool als Wettbewerbsvorteil? (Veto)	Nein — Unterstützungsprozess	Ja — bildet Kern-Know-how ab, soll wachsen
Nutzerkreis	Intern, überschaubar	Externe Kunden/Partner, Anspruch an Oberfläche
Systemlandschaft	Gängige Systeme mit fertigen Konnektoren	Alt-Systeme, Spezial-APIs, eigenes Hosting nötig
Volumen & Last	Innerhalb der Plattform-Kontingente	Datenintensiv, Lastspitzen, viele Automatik-Requests
Änderungsgeschwindigkeit	Fachbereich passt selbst laufend an	Änderungen gebündelt, dafür tiefgreifend
Verfügbare Verantwortung	Niemand kann/will Code-Betrieb verantworten	Es gibt einen Owner für Architektur & Betrieb (intern oder Dienstleister)
Budgetlogik	Laufende Lizenzen akzeptiert, wenig Invest vorab	Invest vorab akzeptiert, laufende Kosten niedrig halten
Exit-Anspruch	Neubau bei Plattformwechsel wäre verkraftbar	Code-Eigentum und Portabilität sind Bedingung
Zeithorizont	Lösung für die nächsten 1–3 Jahre	Fundament für 5+ Jahre

Zeigt die Mehrheit auf Low-Code, aber ein Veto-Kriterium auf Custom (oder umgekehrt): Das ist der klassische Hybrid-Fall aus dem Abschnitt oben.

Umsetzung: So triffst du die Entscheidung in einer Woche

Das Vorgehen, mit dem ich solche Entscheidungen vorbereite — bewusst klein gehalten:

1. Prozess auf eine Seite bringen (½ Tag). Wer macht was, mit welchen Daten, wie oft? Ohne dieses Blatt vergleichst du Werkzeuge für ein Problem, das keiner beschreiben kann.
2. Die zwei Veto-Fragen beantworten (½ Tag, mit Geschäftsführung). Wie komplex ist die Logik wirklich — und ist das Tool Wettbewerbsvorteil oder Unterstützungsprozess? Diese beiden Antworten entscheiden mehr als jeder Plattformvergleich.
3. Matrix durchgehen und Lizenzrechnung aufmachen (1 Tag). Für die Low-Code-Variante: Lizenzkosten pro Nutzer und Jahr auf 3 Jahre hochrechnen, Kontingente gegen das erwartete Volumen prüfen. Für die Custom-Variante: Umsetzungsaufwand plus ehrlichen Wartungsposten ansetzen.
4. Dünnen Durchstich bauen (2–3 Tage). Den riskantesten Teil — meist die komplexeste Logik oder die schwierigste Integration — auf dem favorisierten Weg prototypisch umsetzen. Wenn Low-Code hier schon Workarounds braucht, hast du deine Antwort früh und billig.
5. Entscheiden und Exit dokumentieren (½ Tag). Egal welcher Weg: Schreibe auf, wo die Daten liegen, wie man sie herausbekommt, und wer das System versteht. Das ist die billigste Versicherung des ganzen Projekts.

Risiken und Grenzen — auf beiden Seiten

• Low-Code-Risiko Nr. 1: der schleichende Komplexitätstod. Die App startet simpel und wächst Workaround um Workaround, bis niemand sie mehr versteht — nur eben ohne Versionskontrolle, Tests und Diff-Ansicht. Ab diesem Punkt ist sie teurer zu ändern als Code.
• Low-Code-Risiko Nr. 2: Governance-Lücke. Ohne Regeln, wer Apps mit welchen Rechten bauen darf, entsteht Schatten-IT mit Konnektor-Vollzugriff — die OWASP-Risiken oben sind keine Theorie.
• Custom-Risiko Nr. 1: der ungeplante Betrieb. Software ohne Wartungsbudget verrottet. Wenn niemand Updates, Monitoring und Backups verantwortet, ist Low-Code trotz aller Nachteile die ehrlichere Wahl.
• Custom-Risiko Nr. 2: Overengineering. Ein Urlaubsantrags-Tool braucht keine Microservices. Individuelle Entwicklung lohnt sich nur, wenn die Individualität gebraucht wird.
• Für beide gilt: KI-generierte Inhalte und Logik — ob im Low-Code-Baustein oder in der Codebasis — brauchen menschliche Prüfung; das BSI-Papier zu generativer KI ist als Einstieg in die Risikoanalyse gedacht, nicht als Freifahrtschein.

Was kostet das? (Bandbreiten mit Annahmen)

Konkrete Zahlen hängen vollständig vom Zuschnitt ab; garantieren lässt sich hier nichts. Als Denkrahmen mit offengelegten Annahmen:

• Low-Code: geringer Initialaufwand (oft wenige Personentage für eine erste App, wenn Konnektoren passen), dafür laufende Lizenzkosten pro Nutzer und Monat über die gesamte Lebensdauer — plus interner Pflegeaufwand, der gern unterschätzt wird. Rechne die Lizenzen ehrlich auf 3 Jahre und alle Nutzer hoch, bevor du „günstig” sagst.
• Individuelle Entwicklung: höherer Initialaufwand (ein fokussiertes internes Tool liegt, KI-gestützt und bei klarem Scope, typischerweise im Bereich von Wochen, nicht Monaten), dafür niedrige laufende Kosten (Hosting, Wartungsbudget). Annahmen: Scope ist geklärt, es gibt einen Betriebsverantwortlichen, keine Alt-Datenmigration.
• Der faire Vergleich läuft immer über 3–5 Jahre Gesamtkosten (Lizenzen + interner Aufwand + Umsetzungskosten + Wartung), nie über den Startpreis. Auf diesem Zeithorizont drehen sich viele scheinbar klare Rechnungen.

Wenn du für dein konkretes Vorhaben eine ehrliche Einschätzung willst — auch wenn sie „nehmt Low-Code” lautet —, ist das ein typischer Fall für unsere KI- und Technologieberatung: Scope und Architektur prüfen, bevor gebaut wird. Wenn dein Team Low-Code-Governance oder KI-gestütztes Entwickeln selbst aufbauen soll, sind unsere Schulungen der nachhaltigere Hebel. Und wenn du einfach den Fall einmal durchsprechen willst: Erstgespräch buchen.

Checkliste: Bevor du dich festlegst

1. Prozess auf einer Seite beschrieben? Beteiligte, Daten, Häufigkeit, heutige Schmerzpunkte.
2. Veto-Fragen beantwortet? Logik-Komplexität und „Wettbewerbsvorteil ja/nein” — schriftlich, von der Geschäftsführung mitgetragen.
3. Lizenzrechnung auf 3 Jahre? Alle Nutzer, alle Add-ons, Kontingente gegen erwartetes Volumen geprüft.
4. Wartungsbudget für die Custom-Variante angesetzt? Wenn nein: Wer trägt Betrieb und Updates wirklich?
5. Exit-Szenario für beide Wege durchgespielt? Wie kommen Daten raus, was wäre ein Wechsel, wo liegt das Wissensmonopol?
6. Sicherheitsverantwortung benannt? Bei Low-Code: Rechtemodell, Konnektor-Freigaben, App-Inventar (siehe OWASP-Risiken). Bei Custom: Wer patcht, wer prüft?
7. Hybrid geprüft? Lässt sich der Standard-Rahmen von der differenzierenden Logik per API trennen?
8. Dünner Durchstich am riskantesten Teil gebaut? Erst der Beweis, dann die Grundsatzentscheidung.
9. KI-Anteil geregelt? Wer prüft KI-generierte Logik — egal auf welcher Plattform sie entsteht?
10. Entscheidung dokumentiert? Ein Absatz: gewählter Weg, Gründe, Annahmen, Termin für die Überprüfung in 12 Monaten.

Wer diese zehn Punkte beantworten kann, trifft die Entscheidung nicht nach Bauchgefühl oder Anbieterfolie — sondern so, dass sie auch in drei Jahren noch die richtige war.