Low-Code vs. Custom: Die 12 Fragen, die in B2B-Projekten über Erfolg oder Tech-Schulden entscheiden
Low-Code vs. Custom: Die 12 Fragen, die in B2B-Projekten über Erfolg oder Tech-Schulden entscheiden
Low-Code/No-Code ist 2026 kein Nischenthema mehr. Gartner prognostiziert für Low-Code-Technologien ein Marktvolumen von 44,5 Mrd. USD bis 2026 – die Kategorie ist im Enterprise angekommen. Gleichzeitig erwarten Analysten, dass ein Großteil der Nutzer solcher Tools außerhalb klassischer IT-Abteilungen sitzt.
Das ist gut – weil es Geschwindigkeit bringt. Und es ist gefährlich – weil Geschwindigkeit ohne Leitplanken in B2B-Realität schnell zu Shadow-IT, Qualitätsproblemen und technischen Schulden führt. Genau diese Risiken werden auch in Forschung und Praxis wiederholt beschrieben.
Erst die Wahrheit: Wofür Low-Code wirklich ideal ist
Low-Code ist stark, wenn drei Dinge gleichzeitig gelten:
Der Prozess ist klar und relativ standardisiert
Beispiel: interne Freigaben, Formulare, einfache Workflows, Datenerfassung, Reporting.Die Integrationen sind überschaubar
Beispiel: „lesen“ aus einem System + „schreiben“ in ein zweites – ohne komplexe Businessregeln.Die App ist nicht Ihr Wettbewerbsvorteil
Sie soll funktionieren, nicht differenzieren.
Wenn diese drei Punkte passen, ist Low-Code oft der schnellste Weg zu messbarem Nutzen.
Wo Low-Code in B2B typischerweise kippt
Low-Code kippt selten „plötzlich“, sondern schleichend – immer dann, wenn die App von einem internen Helferlein zu einem produktiven System wird, das Geld, Risiko oder Kundenerlebnis beeinflusst.
Die drei häufigsten Kipp-Punkte:
1) Integrations- und Regelkomplexität
Sobald du Domänenlogik modellierst (Preisregeln, Verfügbarkeiten, Berechtigungen, Ausnahmen, Nachbearbeitung), brauchst du Testbarkeit, Versionierung und klare Verantwortlichkeit. Das wird in Low-Code oft möglich – aber dann meist mit Zusatzaufwand, Spezialwissen und eingeschränkter Portabilität.
2) Security, Rollen, Auditability
B2B heißt: unterschiedliche Rollen, Mandantenfähigkeit, Revisionssicherheit, Nachvollziehbarkeit. Wenn „wer durfte was wann warum“ relevant ist, brauchst du ein Setup, das nicht nur „funktioniert“, sondern beweisbar korrekt ist. Ohne Governance entstehen hier schnell Schattenlösungen und Risiken - genau das ist ein zentraler Punkt in Citizen-Development-Studien.
3) Lifecycle & Betrieb
Wenn eine App 6–24 Monate lebt, ist vieles ok. Wenn sie 5-10 Jahre trägt, brauchst du: saubere Deployments, Monitoring, Ownership, Kostenkontrolle, Exit-Plan. McKinsey beschreibt Low-Code/No-Code auch als Chance, Shadow-IT zu „kanalisieren“ - aber eben nur, wenn IT das aktiv als Asset managt.
Die Entscheidungslogik: 3 Kategorien statt Glaubenskrieg
In der Praxis reichen drei Zielbilder und du solltest jede Initiative bewusst einem davon zuordnen:
A) Low-Code
Für: interne Tools, standardisierte Workflows, Prototyping, begrenzte Integrationen.
Ziel: Time-to-Value.
B) Hybrid
Für: schnelle Oberfläche/Workflow + Custom Backend / APIs für Regeln, Datenhoheit, Security.
Ziel: Speed ohne Kontrollverlust.
C) Custom Development
Für: Kernprozesse, Skalierung, komplexe Integrationen, Compliance, Differenzierung.
Ziel: Langfristige Robustheit.
Das Problem in vielen Unternehmen ist nicht „Low-Code oder Custom“, sondern:
Man startet als A) und landet unbemerkt bei C) – ohne Architektur, ohne Budget, ohne Betriebskonzept.
12 relevante Fragen im Entscheidungsprozess
Strategie & Bedeutung
1) Ist das ein Kernprozess (Umsatz, Produktion, Compliance, Kundenerlebnis)?
2) Wird das in 24 Monaten noch wichtig sein – oder ist es ein Experiment?
Daten & Integrationen
3) Wie viele Systeme müssen wirklich integriert werden (ERP/CRM/DMS/Legacy)?
4) Gibt es komplexe Businessregeln oder viele Ausnahmen/Edge-Cases?
5) Müssen Daten konsistent, transaktional oder near-real-time sein?
Security & Compliance
6) Brauchen wir Mandantenfähigkeit, fein granulare Rollen oder Audit-Logs?
7) Gibt es regulatorische Anforderungen (z. B. Finanz, Public, kritische Infrastruktur, ISO-Audit-Anforderungen)?
Betrieb & Qualität
8) Brauchen wir automatisierte Tests, CI/CD, klare Release-Prozesse?
9) Ist Observability kritisch (Monitoring, Incident-Prozesse, SLOs)?
Kosten & Lock-in
10) Was kostet das bei 200 / 2.000 / 20.000 Nutzern inkl. Lizenzen und Betrieb wirklich?
11) Können wir Daten und Logik sauber exportieren/migrieren (Exit-Plan)?
Organisation
12) Wer ist Owner (Produktverantwortung, Budget, Betrieb) – und ist diese Person in der Lage, Entscheidungen zu treffen?
Fazit: Low-Code ist ein Turbo – aber nur in der richtigen Spur
Low-Code ist großartig, wenn du es als Speed Lane behandelst: standardisierte Prozesse, begrenzte Integrationen, kurzer Lifecycle.
Sobald du Kernprozesse, komplexe Regeln, Compliance oder Skalierung berührst, brauchst du Hybrid oder Custom – sonst kaufst du Geschwindigkeit heute mit Tech-Schulden morgen.
