Von Hakan Akcan · Reepa Solutions
Die Frage „Low-Code oder Custom-Code?“ ist 2026 nicht mehr binär, und sie ist gleichzeitig wichtiger geworden, weil sich die Kostenstrukturen auf beiden Seiten dramatisch verschoben haben. Low-Code-Plattformen sind in den letzten drei Jahren deutlich leistungsfähiger geworden — Microsoft Power Platform, Mendix und OutSystems decken heute Anwendungsfälle ab, die früher zwingend klassische Programmierung verlangten. Gleichzeitig hat die KI-gestützte Code-Generierung die Wirtschaftlichkeit von Custom-Code radikal verändert: was vor zwei Jahren eine Wochenaufgabe für einen Junior-Entwickler war, schreiben Cursor, Claude Code und GitHub Copilot heute in wenigen Stunden. Für Geschäftsführung, CIO und CTO entsteht damit ein dreidimensionales Entscheidungsfeld statt der alten Zwei-Wege-Wahl. Dieser Artikel ordnet die Optionen ein, zeigt welche Use-Cases zu welchem Ansatz passen, beleuchtet das oft verharmloste Lock-in-Risiko und liefert eine Reepa-Empfehlung nach Use-Case. Für die übergeordnete Einordnung siehe unseren Leitfaden Softwareentwicklung sowie den Cluster Custom-Software vs Standard.
Was Low-Code 2026 wirklich kann (und was nicht)
Die Marketing-Versprechen der Low-Code-Anbieter sind ambitioniert: Anwendungen ohne Programmierkenntnisse, zehnmal schnellere Entwicklung, Fachabteilungen bauen ihre Werkzeuge selbst. Die Realität in deutschen Mittelstands-Projekten ist differenzierter. Was Low-Code 2026 tatsächlich gut kann: interne CRUD-Anwendungen mit überschaubarer Logik, Genehmigungs-Workflows, einfache Formular-zentrierte Anwendungen, Integrations-Frontends auf bestehende ERP- oder CRM-Systeme, Prototypen für die Anforderungs-Klärung. In diesen Bereichen sind die Beschleunigungs-Faktoren real — eine Lagerbestands-App, die in klassischer Entwicklung sechs bis acht Wochen kostet, ist in Microsoft Power Apps in zwei bis drei Wochen produktiv.
Was Low-Code 2026 weiterhin nicht gut kann: komplexe Geschäftslogik mit vielen Sonderfällen, Zustandsmaschinen mit dutzenden Übergängen, performance-kritische Datenverarbeitung, anspruchsvolle Mobile-UX, hochgradig anpassbare Suchfunktionen, Echtzeit-Kollaboration, Multi-Tenant-SaaS-Produkte mit Mandanten-Isolation. In diesen Bereichen führen Low-Code-Modelle zu Workarounds, die ab einem gewissen Komplexitäts-Niveau unwartbar werden — der berühmte „Workflow-Spaghetti“, bei dem Hunderte Knoten in einem Drag-and-Drop-Editor versucht haben, das nachzubilden, was zwanzig Zeilen Code sauber gelöst hätten.
Ein häufig unterschätzter Punkt ist die Lernkurve. Die Aussage „Fachabteilungen bauen selbst“ stimmt für triviale Apps. Sobald Datenmodelle, Beziehungen, Sicherheits-Rollen und Integrationen ins Spiel kommen, ist Low-Code-Entwicklung anspruchsvolle Software-Engineering-Arbeit, die nur die Werkzeuge austauscht. In Realität braucht ein produktiver Power-Platform-Entwickler ein bis zwei Jahre Erfahrung — nicht weniger als ein klassischer Web-Entwickler.
Plattformen-Überblick
Der Low-Code-Markt ist 2026 in vier Segmente gespalten, die sich in Zielgruppe, technischer Tiefe und Lock-in-Risiko deutlich unterscheiden. Die folgende Übersicht ist als Orientierung gedacht, keine vollständige Vendor-Bewertung — die Auswahl hängt stark von bestehender IT-Landschaft und Lizenz-Verträgen ab.
| Plattform | Stärke | Zielgruppe | Lock-in |
|---|---|---|---|
| Microsoft Power Platform | Tiefe Microsoft-365-Integration, Dataverse, Copilot-Studio | Microsoft-Kunden, interne Tools, Workflows | Hoch — Dataverse-Bindung |
| Mendix | Enterprise-Anwendungen, Modell-getrieben, gute Governance | Konzerne, größere Mittelständler | Hoch — proprietäres Modell |
| OutSystems | Komplexe Anwendungen, Code-Export-Option, starke ALM | Konzerne mit Custom-Anspruch | Mittel — Java/.NET-Export möglich |
| Retool | Interne Tools für Entwickler, SQL-nah, schnelle Datenbank-UIs | Tech-Teams, Startups, interne Werkzeuge | Mittel — JSON-Export |
| Bubble | Web-Apps ohne Code, gute Community | Gründer, Prototyping, kleine SaaS | Sehr hoch — kein Export |
| Webflow | Marketing-Websites mit CMS, visuelles HTML/CSS | Marketing, kleinere Online-Auftritte | Mittel — HTML/CSS-Export |
| Airtable | Datenbank-Tabellen mit Workflow-Layer, sehr niedrige Schwelle | Fachabteilungen, Listen, kleine Workflows | Mittel — CSV-Export |
Die Auswahl folgt einer einfachen Heuristik: Microsoft-Kunden nehmen Power Platform, weil die Lizenzen meist ohnehin vorhanden sind und die Integration in Teams, SharePoint und Outlook unschlagbar ist. Mendix und OutSystems lohnen sich erst ab einer gewissen Größe — Lizenzen liegen jenseits von 100.000 Euro pro Jahr, dafür ist die Governance-Reife hoch. Retool ist die De-facto-Wahl für Tech-Teams, die schnell interne Werkzeuge bauen wollen ohne ein eigenes Frontend zu schreiben. Bubble ist verbreitet bei Gründern, sollte aber für produktive Geschäftslogik vermieden werden. Webflow ist eine reine Marketing-Site-Lösung. Airtable funktioniert hervorragend als Excel-Ersatz mit Workflow-Schicht für Teams unter 30 Personen.
Use-Case-Matrix: Wann Low-Code, wann Custom-Code
Die wichtigste Entscheidungs-Grundlage ist nicht „welche Plattform“, sondern „passt der Anwendungsfall überhaupt zu Low-Code“. Die folgende Heuristik aus unserer Beratungs-Praxis trennt klar:
- Klar Low-Code geeignetInterne CRUD-Anwendungen, Lagerbestand, Urlaubsanträge, einfache Genehmigungs-Workflows, Frontend für eine bestehende Datenbank, Formulare mit E-Mail-Versand, Microsoft-365-zentrierte Workflows. Schnelligkeit schlägt Tiefe, Lizenzkosten bleiben überschaubar, Fachlogik ist linear.
- Tendenziell Low-Code, aber prüfenMittlere Geschäfts-Workflows mit überschaubarer Logik, Reporting-Frontends, einfache Kunden-Portale ohne hohe UX-Ansprüche, Integrations-Layer zwischen zwei Systemen. Hier lohnt sich ein Proof-of-Concept über zwei Wochen, bevor man sich festlegt.
- Hybrid — Low-Code Frontend, Custom-Code BackendWenn die UI standardisiert ist, aber die Logik komplex — typisches Muster für Vertriebs-Anwendungen mit Preisrechnern oder Konfiguratoren. Frontend in Retool oder Power Apps, Logik als Custom-API in Node, Python oder .NET.
- Klar Custom-Code geeignetKomplexe Geschäftslogik mit vielen Sonderfällen, performance-kritische Anwendungen, Mobile-Native-Apps mit anspruchsvoller UX, Multi-Tenant-SaaS-Produkte, sicherheits-kritische Systeme, Anwendungen mit echtzeitnaher Kollaboration, datenbank-intensive Suchen über Millionen von Datensätzen.
- Klar KI-Code-GenerierungCustom-Code-Projekte mit gut beschreibbaren Anforderungen und kleinem Team — die KI-gestützte Entwicklung mit Cursor oder Claude Code ist in den meisten dieser Fälle 2026 schneller als Low-Code, ohne Lock-in zu erzeugen.
Die schwierigste Kategorie ist die zweite — Anwendungen, bei denen Low-Code „passen könnte“. Hier sehen wir die meisten gescheiterten Projekte, weil die anfängliche Geschwindigkeit über die spätere Wartbarkeit gestellt wurde. Wer in dieser Grauzone eine belastbare Entscheidung treffen will, baut zwei kleine Prototypen — einen in Low-Code, einen mit KI-gestütztem Custom-Code — und vergleicht Entwicklungszeit, Wartungs-Aufwand und Lizenzkosten über drei Jahre.
Low-Code- oder Custom-Code-Entscheidung anstehend?
Sie überlegen, eine interne Anwendung zu bauen und sind unsicher, ob Low-Code, Custom-Code oder ein Hybrid-Modell die richtige Wahl ist? Wir bieten ein 30-minütiges Erstgespräch ohne Kosten — wir bewerten Ihren Use-Case, schätzen Lizenz- und Entwicklungs-Kosten über fünf Jahre und nennen Lock-in-Risiken klar.
Kostenlose Architektur-Beratung anfordernVendor-Lock-in — die unangenehme Realität
Lock-in ist das am meisten unterschätzte Risiko bei Low-Code-Projekten. Die Marketing-Materialien der Anbieter sprechen gerne von „Code-Export“, „Standard-Datenbanken“ und „offenen Schnittstellen“. Die operative Realität ist eine andere. Konkret bedeutet Lock-in in drei Dimensionen: Daten-Lock-in, weil Datenmodelle und Beziehungen in proprietären Formaten gespeichert sind, Logik-Lock-in, weil Workflows und Validierungen in visuellen Editoren modelliert sind, die sich nicht in lesbaren Code übertragen lassen, und Skill-Lock-in, weil das Team über Jahre Plattform-spezifisches Wissen aufbaut, das beim Wechsel verloren geht.
OutSystems und Mendix bieten zwar einen Export in generierten Java- oder .NET-Code an. In der Praxis ist dieser Code nicht wartbar — automatisch generierter Code mit zehntausenden Zeilen ist kein Migrations-Pfad, sondern ein Notfall-Fallback. Realistische Migrations-Strategien sind in der Praxis Re-Implementierungen, deren Aufwand zwischen 70 und 120 Prozent der ursprünglichen Entwicklungs-Kosten liegt. Bubble und Webflow haben keinen ernsthaften Export. Microsoft Power Platform speichert in Dataverse, das technisch eine Microsoft-eigene Datenbank ist — ein Wechsel von Power Apps zu einem anderen System bedeutet zumindest einen vollständigen Datenmodell-Umbau.
Die ehrliche Empfehlung: Lock-in akzeptieren, aber bewusst. Eine Power-Platform-Anwendung mit fünfjähriger Nutzungsdauer und Lizenz-Kosten von 50.000 Euro pro Jahr ist eine Investition, die im Vergleich zur Custom-Entwicklung wirtschaftlich sein kann — solange Sie wissen, dass ein späterer Wechsel eine Re-Implementierung ist. Was nicht passieren darf: Kernprozesse des Unternehmens in eine Plattform mit aggressiven Lizenz-Erhöhungen zu legen, ohne eine kalkulierte Exit-Reserve im Budget. Wir sehen regelmäßig Unternehmen, die nach Lizenz-Verdopplungen einer Plattform die nächsten drei Jahre faktisch keine Verhandlungs-Position mehr haben.
Citizen-Developer-Risiken und Governance
Eines der zentralen Versprechen von Low-Code ist Citizen-Development — Fachabteilungen bauen ihre eigenen Werkzeuge ohne IT-Beteiligung. In der Praxis entstehen ohne Governance vier wiederkehrende Probleme. Erstens Daten-Sicherheits-Risiken: Mitarbeitende verdrahten Excel-Tabellen mit personenbezogenen Daten in Power Apps, ohne den Datenschutzbeauftragten zu beteiligen — DSGVO-Verstöße sind die Folge. Zweitens Schatten-IT: das Inventar verfügbarer Apps wächst unkontrolliert, niemand weiß mehr, welche Anwendungen geschäftskritisch sind. Drittens Single-Point-of-Failure: kritische Workflows hängen an einer Mitarbeiterin, die das Modell vor zwei Jahren gebaut hat und inzwischen das Unternehmen verlassen hat. Viertens unkalkulierbare Lizenz-Kosten: jede neue App treibt die Premium-Lizenz-Anforderungen, das Microsoft-Budget verdoppelt sich in drei Jahren.
Eine wirksame Governance hat sechs Komponenten: ein zentrales Inventar aller produktiven Apps mit Eigentümern und Geschäftskritikalitäts-Einstufung, ein Genehmigungs-Prozess für Apps oberhalb einer definierten Datenklasse, ein zentrales Lizenz-Management mit klarer Kosten-Zuordnung pro Abteilung, definierte Sicherheits-Rollen und Datenquellen, die Citizen-Developer überhaupt verwenden dürfen, regelmäßige Security-Reviews mindestens für alle produktiven Apps, sowie ein Sponsoren-Modell pro Anwendung mit klar benannten Backup-Personen. Microsoft Power Platform liefert mit dem Center of Excellence Starter Kit eine brauchbare Governance-Basis — sie muss aber aktiv betrieben werden.
Hybrid-Modelle: Low-Code für 80%, Custom für 20%
Die strategisch klügste Antwort auf die Low-Code-vs-Custom-Code-Frage ist in vielen mittelständischen Unternehmen ein Hybrid-Modell. Die Idee: triviale Anwendungen — Genehmigungen, Listen, einfache Formulare — laufen auf einer Low-Code-Plattform mit hohem Tempo und niedrigen Entwicklungs-Kosten. Geschäftskritische Anwendungen mit komplexer Logik, hoher Mitarbeiter-Anzahl oder Multi-Mandanten-Charakter laufen als Custom-Code mit klarer Architektur und ohne Lock-in. Konkret heißt das in der Praxis: Microsoft Power Platform für interne Mitarbeiter-Apps, Custom-Code für das Kunden-Portal, Custom-Code für das Vertriebs-Konfigurator-Modul, Retool für die Admin-Oberfläche der Custom-Backend-Datenbanken.
Diese Aufteilung erfordert klare Architektur-Regeln. Hilfreich ist eine Schwellwert-Liste: Apps mit weniger als 50 aktiven Nutzern und linearer Logik laufen auf Low-Code, alles darüber wandert in Custom-Code-Domäne. Apps mit personenbezogenen Daten oberhalb einer definierten Sensitivitäts-Stufe laufen ausschließlich auf vom Sicherheits-Team genehmigten Plattformen. Apps, die externe Kunden erreichen, sind grundsätzlich Custom-Code, weil Lock-in und Skalierungs-Risiken dort am höchsten sind. Diese Regeln gehören in eine schriftliche Plattform-Strategie, die mindestens jährlich aktualisiert wird.
Lizenzkosten realistisch betrachtet
Die Lizenzkosten von Low-Code-Plattformen sind komplex und entwickeln sich oft anders als in der ursprünglichen Kalkulation angenommen. Die folgende Übersicht nennt realistische Bandbreiten für 2026 — präzise Angebote brauchen einen Lizenz-Berater und passen stark zum eigenen Microsoft- oder SAP-Rahmenvertrag.
| Plattform | Pro Nutzer/Monat | Einstiegs-Minimum | Skalierungs-Charakter |
|---|---|---|---|
| Microsoft Power Apps Premium | 20 € pro App-Nutzer | ab 500 € pro Monat | Linear, Konnektor-Zuschläge |
| Mendix Standard | 30–60 € pro Nutzer | ab 1.500 € pro Monat | Stark steigend ab Enterprise |
| OutSystems | auf Anfrage, typisch 80.000–250.000 € p.a. | nicht für kleine Teams | Volumen-Lizenz |
| Retool Business | 50 € pro Nutzer | ab 250 € pro Monat | Linear |
| Bubble | ab 32 € pro Anwendung | günstiger Einstieg | Workload-Kosten skalieren |
| Webflow | 15–50 € pro Site | günstig | Pro Site |
| Airtable Business | 22 € pro Nutzer | ab 110 € pro Monat | Linear |
Wichtig bei der Kalkulation: viele Plattformen haben versteckte Kosten. Microsoft Power Platform verlangt Premium-Konnektor-Lizenzen für viele Datenquellen jenseits von SharePoint und Excel — eine SQL-Server- oder REST-API-Anbindung kann den Lizenz-Preis pro Nutzer verdoppeln. Bubble berechnet Workload-Units, die sich mit der Anwendungs-Komplexität dramatisch erhöhen. Mendix und OutSystems haben jährliche Verhandlungs-Spielräume, sind dafür aber für kleine Teams nicht wirtschaftlich. Eine realistische Total-Cost-of-Ownership-Rechnung über fünf Jahre liegt typischerweise zwei- bis dreimal höher als die initiale Lizenz-Schätzung.
Wartung und Skill-Pool
Ein oft übersehener Faktor ist die langfristige Wartbarkeit und die Verfügbarkeit von Fachkräften. Klassische Custom-Code-Entwicklung mit Stacks wie TypeScript, Python, Java oder .NET hat einen riesigen, globalen Skill-Pool — Sie finden in jeder Stadt Entwickler, die Ihren Code übernehmen können. Low-Code-Skills sind deutlich knapper. Power-Platform-Entwickler mit fünf Jahren Erfahrung sind in Deutschland 2026 selten, Mendix- oder OutSystems-Spezialisten noch seltener. Die Wechsel-Kosten beim Personalausfall sind entsprechend hoch — externe Berater zu Tagessätzen jenseits von 1.400 Euro sind die Regel, nicht die Ausnahme.
Hinzu kommt die Wartungs-Charakteristik der Plattform selbst. Anbieter aktualisieren Komponenten, deprecieren Konnektoren, ändern Lizenz-Modelle. Wer eine Low-Code-Anwendung über fünf Jahre betreibt, hat zwischen drei und fünf Plattform-Migrationen vor sich — oft mit verpflichtenden Anpassungen, weil veraltete Komponenten den Support verlieren. Diese Wartungs-Kosten gehören in die ursprüngliche Kalkulation, weil sie in der Praxis 15 bis 30 Prozent des jährlichen Entwicklungs-Budgets ausmachen können. Detailliertere Diskussion zu Entwicklungs-Kosten siehe unseren Cluster zu Softwareentwicklung Kosten 2026.
KI-Code-Generierung als dritte Alternative
Die wichtigste strategische Veränderung seit 2024 ist die rasante Reifung KI-gestützter Code-Generierung. Cursor, Claude Code und GitHub Copilot haben die klassische Custom-Code-Entwicklung in ihrer Geschwindigkeits-Charakteristik komplett verändert. Eine Aufgabe, die früher ein Junior-Entwickler in einer Woche umgesetzt hat, schreibt ein erfahrener Entwickler mit KI-Unterstützung 2026 in vier bis sechs Stunden. Damit verschiebt sich der Break-even zwischen Low-Code und Custom-Code dramatisch — und in vielen Fällen zugunsten von Custom-Code.
Konkret heißt das: für ein internes Tool mit moderater Komplexität, das früher in Power Apps in zwei Wochen und in Custom-Code in zehn Wochen entstanden wäre, sind die Custom-Code-Zahlen heute eher drei bis vier Wochen. Die Lizenz-Ersparnis über fünf Jahre — keine Power-Platform-Premium-Lizenzen, keine Konnektor-Aufschläge, keine Lock-in-Risiken — übersteigt in vielen Fällen die zusätzlichen Entwicklungs-Kosten. Die ehrliche Schwellen-Frage ist nicht mehr „Low-Code oder Custom-Code“, sondern „Low-Code oder KI-gestütztes Custom-Code“. Letzteres gewinnt 2026 in deutlich mehr Fällen, als die meisten Entscheider vermuten.
Die Voraussetzung ist allerdings Disziplin im Engineering-Prozess. KI-generierter Code ohne Code-Review, ohne automatisierte Tests und ohne Architektur-Vorgaben produziert das gleiche Wartungs-Chaos wie ein unkontrollierter Citizen-Developer-Wildwuchs in Power Apps. Wer KI-gestützte Entwicklung ernsthaft betreibt, braucht ein erfahrenes Senior-Team, das die Architektur vorgibt und Reviews durchführt. Für die Integration mit Workflow-Automatisierung siehe auch unseren Cluster KI-Agenten und n8n-Workflows.
Reepa-Empfehlung pro Use-Case
Aus der Beratungs-Praxis mit deutschen mittelständischen Unternehmen ergibt sich die folgende pragmatische Empfehlung. Sie ist als Ausgangspunkt gedacht, nicht als starre Regel — jede konkrete Entscheidung sollte einen kurzen Architektur-Workshop voraus haben.
- Interne Mitarbeiter-Tools für Microsoft-KundenMicrosoft Power Platform, weil Lizenzen meist vorhanden sind und Teams-Integration unschlagbar ist. Mit klarem Governance-Modell und definiertem Skill-Pool.
- Admin-Oberflächen für eigene DatenbankenRetool, weil schneller als Custom-Frontend zu bauen und mit lesbarem JSON-Export im Fallback nutzbar.
- Kunden-Portal mit eigener MarkeCustom-Code mit KI-Unterstützung. Lock-in vermeiden, UX-Kontrolle behalten, langfristig billiger.
- Multi-Tenant-SaaS-ProduktCustom-Code zwingend. Niemals auf Low-Code-Plattform, weil Lock-in das ganze Geschäftsmodell gefährdet.
- Mobile-Native-App mit Hardware-ZugriffCustom-Code, Flutter oder React Native. Low-Code-Mobile-Wrapper sind 2026 noch nicht produktiv brauchbar.
- Marketing-Website mit CMSWebflow oder ein klassisches Headless-CMS mit Custom-Frontend — abhängig von Marketing-Team-Autonomie-Bedarf.
- Schnelle Listen und Mini-Workflows in FachabteilungenAirtable für Teams unter 30 Personen, sofern Daten nicht hochsensibel sind.
Häufige Fragen
Ist Low-Code wirklich günstiger als Custom-Code?
Kurzfristig in nahezu allen einfachen Fällen ja — eine interne CRUD-Anwendung lässt sich auf Microsoft Power Platform oder Retool in wenigen Tagen statt mehreren Wochen aufbauen. Über drei bis fünf Jahre kippt das Bild häufig: die Lizenzkosten pro Nutzer skalieren linear mit der Anzahl der Mitarbeitenden, während ein einmal entwickeltes Custom-System nur Wartungskosten verursacht. Ab etwa 100 bis 200 aktiven Nutzern oder bei steigender Komplexität rechnen sich Low-Code-Lizenzen oft nicht mehr. Eine seriöse Kalkulation umfasst immer eine fünf-Jahres-Total-Cost-of-Ownership statt nur den ersten Aufwand.
Welche Use-Cases sind für Low-Code definitiv ungeeignet?
Drei Kategorien sollten in der Regel nicht mit Low-Code umgesetzt werden. Erstens komplexe Geschäftslogik mit vielen Sonderfällen, Status-Maschinen und Audit-Anforderungen — die meisten Low-Code-Plattformen modellieren das mit ungelenken Workflow-Bäumen, die nach 50 Knoten unwartbar werden. Zweitens Mobile-Native-Apps mit hohen Performance- oder Hardware-Anforderungen — die Web-Wrapper-Lösungen der meisten Plattformen sind für anspruchsvolle UX zu langsam. Drittens Multi-Tenant-SaaS-Produkte, die Sie selbst vermarkten — Sie geraten in eine doppelte Lock-in-Falle, weil Ihre Endkunden indirekt vom Vendor abhängen.
Wie real ist das Vendor-Lock-in-Risiko bei Low-Code?
Sehr real. Die meisten Low-Code-Plattformen speichern Logik, Datenmodelle und UI in proprietären Formaten, die sich nicht in lesbaren Code exportieren lassen. OutSystems und Mendix bieten zwar Code-Export, der ist aber praktisch nicht wartbar — generierter Code mit Tausenden Zeilen ist kein realistischer Migrations-Pfad. Webflow und Bubble haben keinen ernsthaften Export. Realistisch heißt Wechsel: Re-Implementierung. Deshalb gehört in jede Low-Code-Entscheidung eine bewusste Exit-Strategie und eine kalkulierte Re-Build-Reserve im Budget.
Ist Citizen-Development ein Sicherheitsrisiko?
Ohne Governance ja, mit Governance nein. Wenn Fachabteilungen ohne Aufsicht eigene Power-Apps bauen, entstehen typischerweise drei Probleme: ungeschützte Datenquellen werden in Anwendungen verdrahtet, DSGVO-relevante Datenflüsse laufen am Datenschutzbeauftragten vorbei, und kritische Workflows hängen an einzelnen Personen ohne Backup. Eine wirksame Governance verlangt einen Genehmigungs-Prozess für produktive Apps, ein zentrales Inventar, regelmäßige Security-Reviews und klar definierte Datenklassen, die Citizen-Developer überhaupt verwenden dürfen.
Wird KI-Code-Generierung Low-Code überflüssig machen?
In Teilen ja, vollständig nein. Tools wie Cursor, Claude Code und GitHub Copilot machen die klassische Custom-Code-Entwicklung dramatisch schneller — Aufgaben, für die früher ein Junior-Entwickler eine Woche brauchte, sind heute in Stunden möglich. Damit verschiebt sich der Break-even gegenüber Low-Code zugunsten von Custom-Code. Für reine Standard-Workflows mit vorgefertigten Bausteinen — Genehmigungen, einfache Formulare, Microsoft-365-Integrationen — bleibt Low-Code aber das schnellere Werkzeug. Die ehrliche Empfehlung für 2026 ist ein dreischichtiges Modell: Low-Code für triviale Workflows, KI-gestützter Custom-Code für die Mehrheit der Anwendungen, reines Custom-Code für sicherheits- oder performance-kritische Kerne.
Bereit für eine fundierte Plattform-Entscheidung?
Sprechen wir 30 Minuten unverbindlich. Wir bewerten Ihren Use-Case, schätzen Lizenz- und Entwicklungs-Kosten über fünf Jahre, nennen Lock-in-Risiken klar und schlagen ein passendes Modell vor — Low-Code, Custom-Code oder Hybrid mit KI-Unterstützung.
30-minütiges Gespräch vereinbaren
IT-Sicherheits- und Cloud-Architekt mit über zehn Jahren Erfahrung. Berät mittelständische Unternehmen zu Architektur-Entscheidungen zwischen Custom-Code, Low-Code und KI-gestützter Entwicklung. Schreibt regelmäßig über Softwareentwicklung, Cloud-Security und NIS2.
Geprüft am: 22. Mai 2026 · Mehr über Hakan