Custom-Dev vs. No-Code/Low-Code

No-Code- und Low-Code-Plattformen sind in den letzten fünf Jahren erwachsen geworden. Wer 2026 noch behauptet, sie wären „nur Spielzeug”, hat den Markt nicht angeschaut. Gleichzeitig sehen wir regelmäßig Projekte, die auf einer No-Code-Plattform gestartet sind und nach 12–24 Monaten an drei Stellen reißen — fast immer denselben. Hier ist die ehrliche Heuristik, wann welcher Pfad trägt.

Was die Begriffe wirklich abdecken

• No-Code (Bubble, Glide, Softr, Adalo). Visuelle App-Builder. Datenmodell, UI und Workflow werden im Browser zusammengeklickt. Code schreibt man höchstens für Edge-Cases.
• Low-Code (Retool, Appsmith, Internal, Mendix, OutSystems). Visuelle Builder mit Code-Pfaden. Die Mehrheit wird konfiguriert, kritische Stellen werden per JavaScript/SQL/Python ergänzt. Stark im Internal-Tools-Bereich.
• Workflow-Automation (Zapier, Make, n8n). Strikt genommen kein App-Builder, sondern Glue-Code zwischen SaaS-Tools. Wird oft in einem Atemzug genannt.
• No-Code-Marketing-Sites (Webflow, Framer). Ein anderer Use-Case als App-Building — gehört eher in die Diskussion „WordPress vs. statischer Site-Builder”, weniger in „App-Plattform vs. Custom”.

Custom-Dev meint hier eigene Codebasis: TypeScript, React/Next/Astro/React Native, eigene Backend-Services, eigenes DB-Schema. Volle Kontrolle, volle Verantwortung, volle Wartungslast.

Wo No-Code überzeugt

Vier Setups, in denen No-Code/Low-Code der richtige Pfad ist:

1. Schnelle Validierung

Wenn du eine Hypothese testen willst, bevor du baust, ist No-Code ein außergewöhnlich starkes Werkzeug. Eine Buchungs-Plattform für eine Nische, die du in zwei Wochen auf Bubble baust, validiert in einem Monat reales Nutzerverhalten — was im Custom-Build sechs Monate gedauert hätte. Stirbt die Hypothese, hast du nichts verloren. Trägt sie, hast du die richtige Spezifikation für den späteren Custom-Build.

2. Internes Tool, kleines Nutzerfeld

Ein internes Approval-Tool für 15 Mitarbeiter:innen, ein Reporting-Dashboard für eine Geschäftsleitung, eine Lager-Übersicht für drei Standorte — Retool und Konsorten sind dafür gebaut. Internal-Tools-Plattformen ziehen ihren Wert genau aus diesen Use-Cases: schnell, robust, niedriger Wartungsaufwand, Anbindung an bestehende Datenbanken im Drag-and-Drop. Wer hier mit Custom-Dev startet, baut typischerweise einen Bruchteil der Funktionalität mit dem doppelten Aufwand.

3. Single-Workflow-Apps für definierten Nutzerkreis

Wenn deine App genau eine Sache tut — ein Formular ausfüllen, einen Termin buchen, einen Status melden — und der Nutzerkreis stabil ist (eigene Mitarbeiter:innen, Stamm-Endkunden, kleiner Verein), reicht No-Code lange. Manche dieser Setups laufen bei Auftraggeber:innen seit Jahren stabil und sollten nicht angefasst werden.

4. Marketing-Mikroservices

Landing-Pages, Lead-Forms mit Conditional Logic, Newsletter-Signups mit Routing — alles, was zwischen einer Marketing-Kampagne und einem Backend lebt. Webflow + Make + ein Airtable als „Datenbank” tragen Hunderte von Marketing-Setups. Custom-Dev wäre hier Overkill.

Vier typische Reißpunkte

Nach unserer Erfahrung kippt No-Code an vier Stellen in Custom-Dev-Bedarf — fast immer in dieser Reihenfolge:

1. Datenmodell-Tiefe

No-Code-Plattformen sind großartig bei flachen Datenmodellen (Liste von Items, Liste von Usern, einfache 1:n-Beziehungen). Sobald deine Domäne 4+ verbundene Entitäten mit komplexen Constraints, Lifecycle-States und Aggregations-Anforderungen hat, beginnt der Workaround-Modus: doppelte Tabellen, manuelle Sync-Schritte, Logik-Bypässe in externen Tools. Jeder Workaround macht das System zerbrechlicher.

Faustregel: wenn du anfängst, „kleine” Skripte außerhalb der No-Code-Plattform zu schreiben, um Datenintegrität zu sichern, sitzt du bereits zwischen den Stühlen.

2. Performance bei wachsenden Daten- oder User-Mengen

No-Code-Plattformen rendern UIs typisch über generische Engines. Bei einem Datensatz von wenigen Tausend Einträgen ist das egal. Bei mehreren Hunderttausend oder bei vielen gleichzeitigen Usern wird es spürbar — und du hast keine Stellschrauben außer „mehr Plan buchen”. Wenn dein Wachstumspfad sichtbar in diese Region zeigt, lohnt sich der Custom-Pfad früher, nicht später.

3. Compliance und Self-Host

DSGVO-kritische Verarbeitung, Branchen mit dokumentationspflichtigen Daten-Pfaden, Verträge mit Endkunden, die Self-Hosting verlangen — die meisten No-Code-Plattformen sind US-zentrisch und bieten On-Prem nicht oder nur in teuren Enterprise-Tarifen. Sobald eine Aufsicht oder ein Großkunde harte Anforderungen stellt, ist der Wechsel oft alternativlos. Mehr zu DSGVO-Pflichten im Wartungsbetrieb steht in DSGVO-Wartungspflichten für Apps.

Wir haben mehrere Migrationen gesehen, in denen ein erfolgreiches Bubble-Produkt auf eine Custom-Plattform umgezogen ist — nicht weil das Produkt nicht funktionierte, sondern weil eine Aufsichtsanforderung kein US-Hosting mehr erlaubte.

4. Lock-in und Lizenzkosten bei Wachstum

No-Code-Plattformen skalieren ihre Preise mit User-Zahl, Datensatz-Volumen oder Workflow-Aufrufen. Bei kleinem Setup günstig, bei Wachstum teuer. Vergleichsrechnungen über drei Jahre kippen oft erstaunlich früh: ein Custom-Build mit AppCare im mittleren vierstelligen Bereich pro Monat ist bei Setups mit 5.000+ aktiven Usern häufig billiger als ein No-Code-Tarif derselben Größenordnung.

Dazu kommt der Lock-in: viele No-Code-Plattformen bieten keinen sauberen Code-Export. Wenn du wechseln willst, baust du neu — kein rechtlicher Lock-in, aber ein realer Schwellenwert.

Migrations-Heuristik: wann der Wechsel passt

Wenn deine No-Code-App heute läuft, ist „migrieren wir nach Custom” selten die richtige Frage. Die richtige Frage ist: läuft die App so, dass sie noch 18 Monate trägt, oder kippt einer der Reißpunkte schon?

• Datenmodell-Tiefe wächst, externe Skripte häufen sich → Migrations-Plan auf 6–12 Monate ansetzen, parallel betreiben, kontrolliert umstellen.
• Compliance-Anforderung wird konkret → harter Stichtag, Migration als Projekt mit fixem Endtermin planen. Self-Host-Stack vorab definieren.
• Lizenzkosten ziehen über drei Jahre weg → TCO-Vergleich rechnen. Bei erreichtem Schwellenwert hat ein Custom-Build oft eine Amortisation unter 18 Monaten.
• Performance-Engpass wird operativ spürbar → Custom für die heißen Pfade, No-Code für die kalten. Hybrid-Setups sind eine valide Endstation, nicht nur eine Übergangslösung.

In der Praxis empfehlen wir Auftraggeber:innen ohne validiertes Produkt regelmäßig No-Code-Piloten — gerade dann, wenn ein Custom-Build in der jetzigen Phase überdimensioniert wäre. Custom kommt ins Spiel, wenn die Reißpunkte sichtbar werden, nicht prophylaktisch.

Was Sovion baut (und was nicht)

Wir bauen Custom-Dev. Sobald ein Pfad durch No-Code besser bedient ist, sagen wir das ehrlich — auch wenn wir damit ein Mandat verlieren. Was wir nicht machen: No-Code-Setups produktiv aufsetzen oder warten. Dafür gibt es Spezialist:innen mit besseren Workflows.

Was wir machen: bestehende No-Code-Apps als technische Basis analysieren, einen Migrations-Pfad zeichnen und den Eigenbau parallel oder als Ablösung umsetzen. Wenn du gerade an einem Reißpunkt stehst, gehen wir den Stand mit dir durch — beschreib deine App in drei Sätzen (Plattform, Anzahl Nutzer:innen, größte aktuelle Reibung) über das Kontaktformular. Antwort in 24 Stunden, ohne Sales-Pipeline.

Mehr Kontext: Native vs. Cross-Plattform vs. PWA für die Stack-Frage nach der No-Code-Migration. Eigene Plattform bauen vs. SaaS mieten, wenn die Frage nicht „No-Code oder Custom”, sondern „Standard-SaaS oder Custom” ist.