Low-code vs. maßgeschneiderte app-entwicklung: wo liegen die grenzen?

Low-Code-Plattformen versprechen Tempo, niedrigere Kosten und mehr Unabhängigkeit von knappen Entwicklerressourcen, und sie gewinnen in Unternehmen seit Jahren an Boden. Doch je stärker Prozesse digitalisiert werden, desto öfter stellt sich die Gretchenfrage: Reicht das Baukastensystem noch, oder beginnt an einer bestimmten Stelle die Domäne der maßgeschneiderten App-Entwicklung? Wer die Grenzen zu spät erkennt, zahlt doppelt, mit Workarounds, technischen Schulden und Sicherheitsrisiken. Dieser Überblick zeigt, wo Low-Code überzeugt, wo es typischerweise scheitert, und welche Kriterien bei der Entscheidung wirklich zählen.

Wenn Geschwindigkeit wichtiger ist als Perfektion

Es gibt Situationen, in denen Low-Code nicht nur „gut genug“ ist, sondern die wirtschaftlich vernünftigste Option. Typisch ist alles, was schnell produktiv gehen muss, klar umrissene Abläufe hat und sich ohne tiefe Systemeingriffe abbilden lässt: interne Self-Service-Tools, Formulare, einfache Genehmigungsprozesse, Prototypen für Fachbereiche, oder auch das Digitalisieren von Excel- und E-Mail-Ketten, die längst zu Schatten-IT geworden sind. Hier spielt Low-Code seine Stärke aus, weil es Standardbausteine für UI, Datenmodelle, Workflows und Benachrichtigungen mitbringt, und weil Änderungen oft ohne monatelange Release-Zyklen möglich sind.

Der Markt liefert dafür handfeste Indikatoren, wie groß der Bedarf ist. Analysten wie Gartner haben Low-Code in den vergangenen Jahren als einen der zentralen Hebel zur Beschleunigung der Softwarebereitstellung beschrieben, auch weil Unternehmen unter Druck stehen, neue digitale Services schneller bereitzustellen, als klassische Entwicklungsmodelle es erlauben. Gleichzeitig ist „schnell“ nicht gleich „billig“: Lizenzmodelle, nutzungsbasierte Abrechnung und zusätzliche Kosten für Konnektoren, Monitoring oder Governance können die Rechnung verändern. Dennoch bleibt Low-Code attraktiv, wenn der Nutzen unmittelbar ist, das Risiko begrenzt bleibt, und wenn man früh akzeptiert, dass es sich um eine Lösung für definierte Zwecke handelt, nicht um eine Universalplattform.

Ein weiterer Pluspunkt ist die Nähe zum Fachbereich. Wenn Citizen Developer unter klaren Leitplanken arbeiten, entstehen Lösungen oft näher am tatsächlichen Prozess, und die Akzeptanz im Team steigt. Aber genau hier beginnt auch die Grenze: Sobald „jede Abteilung ihr eigenes Tool baut“, drohen Inkonsistenzen bei Daten, Rollen, Compliance und Support. Low-Code ist dann schnell, bis es das nicht mehr ist, weil die Organisation die Steuerung nachholen muss, und die vermeintliche Beschleunigung durch spätere Konsolidierung aufgefressen wird.

Wo Low-Code an harte Grenzen stößt

Der Moment der Wahrheit kommt meist nicht im Demo-Meeting, sondern im Betrieb. Denn Low-Code-Plattformen sind auf Standardfälle optimiert, und sie geraten ins Schwimmen, wenn Anforderungen stark vom „Happy Path“ abweichen. Dazu zählen komplexe Geschäftslogik mit vielen Ausnahmen, hochgradig individualisierte Nutzeroberflächen, anspruchsvolle Offline-Szenarien, oder Anwendungen mit sehr hohen Anforderungen an Performance und Latenz. Wer einmal versucht hat, eine differenzierte Berechtigungslogik, mehrstufige Freigaben mit Sonderfällen und revisionssichere Audit-Trails in einem reinen Baukastensystem abzubilden, weiß: Irgendwann entstehen Workarounds, und Workarounds sind selten wartbar.

Auch Integrationen sind ein klassischer Stolperstein. Ja, viele Plattformen bieten Konnektoren, doch in der Praxis hängt die Komplexität an Details: proprietäre Schnittstellen, unvollständige APIs, Event-getriebene Architekturen, oder Systeme, die aus Sicherheitsgründen nicht direkt erreichbar sind. Spätestens wenn man eigene Middleware, API-Gateways, Message-Queues oder spezielle Verschlüsselung einziehen muss, verschiebt sich die Arbeit in den „Pro-Code“-Bereich, und das Team benötigt ohnehin erfahrene Entwicklerinnen und Entwickler. Dann stellt sich die Frage, ob die Low-Code-Schicht noch Nutzen stiftet, oder ob sie lediglich zusätzliche Abhängigkeiten schafft.

Ein weiteres, oft unterschätztes Feld ist die Portabilität. Vendor-Lock-in ist kein theoretisches Risiko, sondern eine betriebliche Realität, wenn Geschäftsprozesse, Datenmodelle und UI-Logik tief in einer Plattform stecken. Ein späterer Wechsel kann so teuer werden wie eine Neuentwicklung, und das ist eine harte Grenze für Unternehmen, die strategisch unabhängig bleiben wollen. Hinzu kommen Governance und Security: Rollenmodelle, Datenklassifizierung, Protokollierung, DSGVO-Prozesse, sowie der Umgang mit personenbezogenen Daten in Test- und Staging-Umgebungen müssen sauber gelöst sein. Low-Code kann das unterstützen, aber es ersetzt kein Sicherheitskonzept, und es entschuldigt keine fehlenden Kontrollen.

Maßgeschneidert heißt nicht automatisch teuer

Die Vorstellung, individuelle App-Entwicklung sei zwangsläufig langsam und kostspielig, ist zu grob. Maßgeschneidert bedeutet zunächst: Architektur, Technologie-Stack und Betriebsmodell werden an das Produkt angepasst, und nicht umgekehrt. Das kann teurer sein, wenn man jeden Wunsch ohne Priorisierung umsetzt, doch es kann auch günstiger werden, wenn man früh richtig entscheidet, sauber modularisiert, und unnötige Plattformkosten vermeidet. Gerade bei Produkten mit langer Lebensdauer, vielen Integrationen und hohen Qualitätsanforderungen ist eine individuell entwickelte Lösung oft die stabilere Investition, weil sie technische Schulden kontrollierbarer macht, und weil Wartbarkeit nicht von den Roadmaps eines Anbieters abhängt.

Entscheidend ist außerdem, dass moderne Entwicklungsansätze den klassischen „Wasserfall“ längst abgelöst haben. Agile Delivery, Continuous Integration, automatisierte Tests, Infrastruktur als Code und Cloud-native Betriebsmodelle können die Time-to-Market erheblich verkürzen, ohne die Kontrolle über Code, Sicherheit und Daten zu verlieren. Wer sauber plant, beginnt nicht mit der „perfekten“ Komplettlösung, sondern mit einem Minimum Viable Product, und erweitert danach schrittweise. So entsteht ein Produkt, das zu den tatsächlichen Nutzungsdaten passt, statt zu Annahmen aus Workshops, und das Team kann früh messen, ob Performance, Conversion oder Prozesszeiten wirklich besser werden.

Hinzu kommt ein Aspekt, der in Budgetdebatten oft fehlt: Die Kosten eines Systems entstehen nicht nur beim Bau, sondern über Jahre im Betrieb, in der Weiterentwicklung, im Support und bei der Absicherung. Eine maßgeschneiderte App kann hier punkten, wenn sie observability-fähig ist, wenn sie klare Schnittstellen besitzt, und wenn sie sich in die vorhandene IT-Landschaft sauber einfügt. Umgekehrt kann Low-Code im laufenden Betrieb teuer werden, wenn Lizenzkosten mit der Nutzerzahl wachsen, wenn Anpassungen nur über teure Add-ons möglich sind, oder wenn jede Sonderlogik als Kompromiss implementiert werden muss. Wer eine neutrale Einschätzung und eine solide Umsetzungsplanung sucht, findet unter swisstomato.ch/de einen Einstieg in Themen rund um Konzeption, Entwicklung und Betrieb digitaler Produkte, ohne dass das Projekt von Beginn an in ein starres Schema gezwungen wird.

Die richtige Entscheidung fällt im Pflichtenheft

Die Grenze zwischen Low-Code und individueller Entwicklung ist selten ideologisch, sie ist operativ. Sie lässt sich am besten erkennen, wenn Anforderungen präzise beschrieben und priorisiert werden, nicht als Wunschliste, sondern als prüfbare Kriterien: Welche Prozesse müssen revisionssicher sein, welche Daten sind kritisch, welche Integrationen sind zwingend, welche Nutzerzahlen sind realistisch, und welche Antwortzeiten sind tolerierbar? Sobald man das in messbare Ziele übersetzt, wird klar, ob eine Plattform die Anforderungen nativ erfüllt, oder ob man sich in Ausnahmen verheddert. Ein Pflichtenheft ist dabei kein bürokratisches Monster, sondern ein Schutz vor späteren Überraschungen, weil es Abhängigkeiten, Risiken und Verantwortlichkeiten sichtbar macht.

Praktisch bewährt sich ein zweistufiges Vorgehen. Erstens: Ein kurzer, aber harter Architektur- und Sicherheitscheck, der klärt, ob Datenhaltung, Identity-Management, Logging, Backup-Strategie und Compliance-Anforderungen abbildbar sind. Zweitens: Ein Prototyp, der nicht nur „klickt“, sondern die schwierigsten Teile testet, also Integrationen, Berechtigungen, Sonderfälle und Last. Wer im Prototyp nur die schöne Oberfläche baut, trifft später falsche Entscheidungen. Wer dagegen die härtesten Anforderungen zuerst testet, reduziert Risiko und kann realistisch kalkulieren, inklusive Betrieb, Support und Weiterentwicklung.

Am Ende ist die beste Lösung oft hybrid. Low-Code kann als Frontend für interne Tools dienen, während kritische Kernlogik als Service in sauberem Code läuft, oder man nutzt Low-Code für schnelle Prozessdigitalisierung und setzt für kundennahe Produkte auf maßgeschneiderte Entwicklung. Wichtig ist, dass die Architektur diese Trennung unterstützt, und dass Governance-Regeln verhindern, dass sich Schatten-IT in der Plattform ausbreitet. Die Grenze verläuft also nicht nur technisch, sondern auch organisatorisch: Wer Ownership, Wartung und Verantwortlichkeiten nicht klärt, wird mit jeder Option scheitern, und wer sie klärt, kann aus beiden Welten das Beste ziehen.

So planen Sie Budget und Starttermin

Wer schnell starten will, sollte zuerst die Anforderungen priorisieren, dann einen Prototyp für die kritischen Integrationen bauen, und anschließend den realistischen Betrieb kalkulieren. Reservieren Sie früh Kapazitäten für Security, Datenschutz und QA, denn diese Themen kosten sonst Zeit kurz vor dem Launch. Prüfen Sie Förderprogramme und Digitalisierungsinitiativen in Ihrer Region, und planen Sie ein Budget für laufende Weiterentwicklung ein, nicht nur für den Build.