Was Low-Code und No-Code tatsächlich leisten
Low-Code und No-Code versprechen schnelle Anwendungsentwicklung ohne klassisches Programmieren. In der Praxis verschwimmen die Grenzen. Entscheidend ist nicht die Marketing-Kategorie, sondern was die Plattform konkret kann und wo sie aufhört.
Low-Code (Mendix, OutSystems, Retool, Appsmith) kombiniert visuelle Editoren mit der Möglichkeit, eigenen Code einzufügen. Zielgruppe: Entwickler und technisch versierte Mitarbeitende.
No-Code (Bubble, Glide, Airtable, Softr) setzt komplett auf Drag-and-Drop. Zielgruppe: Fachabteilungen ohne Programmierkenntnisse.
Der Unterschied ist graduell. Bubble erlaubt mittlerweile Custom Plugins mit JavaScript. Retool ist “Low-Code”, aber ohne SQL-Kenntnisse kaum nutzbar. Die Labels sind Marketing.
Direktvergleich: Wo liegen die echten Unterschiede?
| Kriterium | Low-Code | No-Code |
|---|---|---|
| Typische Plattformen | OutSystems, Mendix, Retool, Appsmith | Bubble, Glide, Airtable, Softr |
| Benötigte Vorkenntnisse | SQL, API-Grundlagen, etwas Code | Keine, aber logisches Denken hilft |
| Maximale App-Komplexität | Multi-Tenant SaaS, komplexe Workflows | Einfache CRUD-Apps, Formulare, Dashboards |
| Custom Code | Ja (JS, SQL, manchmal Python) | Nein oder stark eingeschränkt |
| API-Integrationen | Beliebig via REST/GraphQL | Vorgefertigte Connectoren, begrenzt |
| Typische Kosten (pro Jahr) | 15’000-80’000 CHF (Team-Lizenzen) | 1’200-12’000 CHF (Seat-basiert) |
| Vendor Lock-in | Hoch (proprietäre Runtime) | Sehr hoch (kein Code-Export) |
| Datenhoheit | Teilweise konfigurierbar | Meist beim Anbieter |
Wann No-Code die richtige Wahl ist
No-Code funktioniert, wenn drei Bedingungen erfüllt sind:
- Die Anforderungen ändern sich selten. Ein internes Inventar-Tool, ein Anmeldeformular, ein einfaches Dashboard.
- Es gibt keinen Entwickler im Team. Wenn die Alternative “gar keine Lösung” heisst, ist No-Code besser als Excel.
- Die Datenmenge bleibt klein. Unter 10’000 Datensätze, wenige gleichzeitige Nutzer.
Konkretes Beispiel: Ein HR-Team baut mit Airtable + Softr ein Bewerbungsportal. 200 Bewerbungen pro Monat, 5 interne Nutzer. Funktioniert problemlos. Kosten: ca. 50 CHF/Monat.
Wo es kippt: Das gleiche Team will nun automatisierte Vertragsgeneration, Anbindung an SAP SuccessFactors und ein Berechtigungssystem mit 4 Rollen. Airtable stösst an die Grenze. Migration zu einer echten Anwendung kostet jetzt mehr, als wenn man direkt gebaut hätte.
Wann Low-Code Sinn ergibt
Low-Code ist sinnvoll für:
- Interne Tools mit Datenbankzugriff (Admin-Panels, Reporting-Dashboards)
- Prototypen, die Stakeholdern zeigen, wie eine App funktionieren könnte
- Prozessautomatisierung mit komplexeren Regeln (Genehmigungsworkflows, mehrstufige Formulare)
Konkretes Beispiel: Ein Logistik-Unternehmen baut mit Retool ein Dashboard, das Daten aus PostgreSQL, einer REST-API und Google Sheets zusammenführt. 3 Wochen Entwicklung statt 3 Monate. Kostenersparnis: ca. 40’000 CHF gegenüber Custom-Entwicklung.
Aber: Die Retool-Lizenz kostet 600 USD/Monat für 5 Entwickler. Nach 3 Jahren hat man 21’600 USD bezahlt und besitzt trotzdem nichts. Bei Retool-Preiserhöhung oder Feature-Änderung hat man keine Alternative.
Das Vendor-Lock-in-Problem, über das niemand spricht
Die grösste Schwäche beider Ansätze ist identisch: Sie besitzen den Code nicht.
- OutSystems generiert .NET-Code, der ohne die OutSystems-Runtime nicht lauffähig ist.
- Bubble hat keinerlei Export-Funktion. Ihre Anwendung existiert nur auf Bubble-Servern.
- Mendix bietet theoretisch einen Export, aber der generierte Java-Code ist praktisch unwartbar.
Was das konkret bedeutet:
- Preiserhöhung? Sie zahlen oder bauen neu.
- Plattform wird eingestellt? Alles weg. (Passiert regelmässig: Google App Maker 2021, Amazon Honeycode 2024.)
- Performance-Problem? Sie können nichts optimieren, was die Plattform nicht erlaubt.
Faustregel: Je geschäftskritischer eine Anwendung, desto gefährlicher ist Vendor Lock-in.
Welche Datenschutz-Risiken bringen Low-Code und No-Code mit sich?
Seit dem revidierten Datenschutzgesetz (nDSG/FADP), das am 1. September 2023 in Kraft trat, gelten in der Schweiz strengere Anforderungen an die Bearbeitung von Personendaten. Parallel dazu greift die DSGVO für jedes Unternehmen, das Daten von EU-Bürgern verarbeitet. Beide Regelwerke betreffen Low-Code und No-Code direkt.
Wo es kritisch wird:
- Datenstandort: Bubble hostet ausschliesslich auf AWS in den USA. OutSystems bietet EU-Rechenzentren, aber keine Schweizer Standorte. Wer Personendaten auf einer US-Plattform verarbeitet, muss seit dem Wegfall des Privacy Shield (und trotz des neuen Data Privacy Framework) sicherstellen, dass die Übermittlung rechtmässig ist. Das nDSG verlangt bei Transfers in Länder ohne angemessenes Schutzniveau zusätzliche Schutzmassnahmen.
- Auftragsbearbeitung: Das nDSG fordert klare Vereinbarungen mit Auftragsbearbeitern (Art. 9 nDSG). Bei No-Code-Plattformen ist oft unklar, welche Sub-Auftragsbearbeiter involviert sind. Bubble listet über 20 Drittanbieter in seiner Privacy Policy.
- Auskunfts- und Löschrechte: Betroffene haben das Recht auf Auskunft und Löschung. Bei Plattformen ohne direkten Datenbankzugriff (Bubble, Glide) ist die vollständige Löschung aller Kopien, Backups und Logs nicht garantiert.
- Protokollierung: Für automatisierte Einzelentscheidungen und Profiling verlangt das nDSG Transparenz. Low-Code-Plattformen mit eingebauter “KI-Logik” (z.B. OutSystems AI Mentor) machen die Nachvollziehbarkeit schwierig.
Regulierte Branchen: Die FINMA (Finanzmarktaufsicht) und Swissmedic stellen zusätzliche Anforderungen. Ein Finanzdienstleister, der Kundendaten auf einer Plattform verarbeitet, deren Quellcode er nicht auditieren kann, hat ein Compliance-Problem. Gleiches gilt für Gesundheitsdaten unter dem Humanforschungsgesetz.
Wo werden die Daten gehostet? DACH-Optionen im Überblick
Datenresidenz ist kein abstraktes Compliance-Thema, sondern eine operative Realität. Viele Schweizer Unternehmen sind vertraglich verpflichtet, Daten in der Schweiz oder zumindest im EWR zu halten.
| Plattform | Hosting-Standorte | Schweizer Rechenzentrum? | Self-Hosting möglich? |
|---|---|---|---|
| Bubble | AWS US (Virginia) | Nein | Nein |
| OutSystems | AWS EU (Frankfurt, Ireland) | Nein | Ja (Enterprise) |
| Mendix | AWS/Azure, EU-Regionen verfügbar | Nein | Ja (Private Cloud) |
| Retool | AWS US, EU auf Anfrage | Nein | Ja (Self-Hosted) |
| Appsmith | Cloud: AWS US | Nein | Ja (Open Source) |
| Ruby on Rails | Frei wählbar | Ja (z.B. Exoscale, Infomaniak) | Ja |
Die pragmatische Lösung: Appsmith und Retool bieten Self-Hosting. Damit lassen sich Daten auf Schweizer Infrastruktur (Exoscale in Zürich, Infomaniak in Genf) betreiben. Für geschäftskritische Anwendungen bleibt Custom-Entwicklung mit Rails der einzige Weg, volle Kontrolle über Hosting, Verschlüsselung und Zugriffsprotokolle zu behalten.
Warum wir diesen Ansatz bei USEO gewählt haben
Ein konkretes Beispiel aus unserer Arbeit: Ein Schweizer Logistikdienstleister hatte seine Sendungsverfolgung auf Bubble aufgebaut. Nach 14 Monaten stiess das Team an drei Wände gleichzeitig: die Performance brach bei über 500 gleichzeitigen Nutzern ein, ein Grosskunde verlangte vertraglich Datenresidenz in der Schweiz (die Bubble nicht bieten konnte), und die FINMA-nahe Compliance-Abteilung des Kunden wollte den Quellcode auditieren.
Wir migrierten die Anwendung zu Ruby on Rails, gehostet auf Exoscale in Zürich. Die Migration dauerte 5 Monate und kostete rund 95’000 CHF. Der Bubble-Prototyp hatte über seine Laufzeit bereits 85’000 CHF gekostet (Lizenzen, Workarounds, externe Bubble-Entwickler). Hätte das Team direkt mit Rails gebaut, wäre das Gesamtbudget bei ca. 80’000 CHF geblieben.
Was wir in über 10 Jahren bei Dutzenden Projekten beobachten:
- No-Code-Projekte werden zu teuren Altlasten. Bubble kennt keinen Code-Export. “Migration” bedeutet: alles neu bauen und dabei 60-80% der Originalkosten nochmals investieren.
- Low-Code ersetzt keine Architekturentscheidungen. Retool-Dashboards mit 30+ Queries und verschachtelter Logik sind genauso unwartbar wie schlecht geschriebener Code, nur dass man kein Git, keine Tests und kein Review hat.
- Die “Citizen Developer”-Vision funktioniert selten. In der Theorie bauen Fachabteilungen eigene Apps. In der Praxis rufen sie nach 2 Wochen die IT, weil ein API-Call nicht funktioniert.
- Datenschutz wird zum Dealbreaker. Seit dem nDSG fragen unsere Kunden systematisch nach Datenstandort und Auftragsbearbeitung. Plattformen ohne Schweizer Hosting-Option fallen bei regulierten Kunden sofort raus.
Wann wir trotzdem Low-Code empfehlen:
- Interne Tools, die maximal 12 Monate leben sollen
- Quick-and-dirty Prototypen zur Anforderungsklärung (danach wegwerfen)
- Kleine Automatisierungen (Zapier/Make reicht oft)
Wann wir abraten:
- Alles, was Kunden direkt sehen (Performance, SEO, Barrierefreiheit)
- Anwendungen mit mehr als 5 Datenbank-Tabellen und Beziehungen
- Regulierte Branchen, die Audit-Trails und Datenhoheit verlangen (FINMA, Swissmedic)
Entscheidungsmatrix für technische Entscheider
| Frage | Antwort A | Antwort B |
|---|---|---|
| Wer nutzt die App? | Nur internes Team (max. 20 Personen) | Kunden oder Partner |
| Wie lange soll sie laufen? | Unter 12 Monate | Über 12 Monate |
| Gibt es einen Entwickler? | Nein | Ja |
| Komplexe Geschäftslogik? | Nein, simple CRUD | Ja, Regeln und Workflows |
| Datenschutzanforderungen? | Standard | Erhöht (Finanz, Gesundheit) |
Mehrheit A: No-Code ist eine Option. Mehrheit B: Custom-Entwicklung oder allenfalls Low-Code für den Prototyp. Mischung: Starten Sie mit Low-Code, aber planen Sie die Migration ein.
Integration mit bestehenden Rails-Anwendungen
Für Teams mit einer Rails-Codebasis gibt es pragmatische Kombinationen:
- Retool/Appsmith als Admin-Panel: Direkte Anbindung an die PostgreSQL-Datenbank. Spart die Entwicklung eines eigenen Admin-Bereichs. Aber: Read-Only empfohlen, Schreibzugriffe über die Rails-API routen.
- Zapier/Make für Glue-Code: Webhooks aus Rails triggern Aktionen in Dritten (Slack-Benachrichtigungen, CRM-Updates). Funktioniert für bis zu ca. 1’000 Ausführungen/Monat kosteneffizient.
- Bubble/Glide als Frontend? Funktioniert technisch, aber die API-Performance ist unvorhersehbar. Wir raten davon ab.
Der bessere Ansatz: Rails liefert die API, ein schlankes Frontend (Hotwire, Stimulus) liefert die UI. Kein Vendor Lock-in, volle Kontrolle, und die Entwicklungsgeschwindigkeit mit Rails 7+ und Hotwire ist vergleichbar mit Low-Code.
Versteckte Kosten: Was die Anbieter nicht erwähnen
- Bubble: Ab 10’000 Workflows/Monat steigen die Kosten sprunghaft. Ein Kunde zahlte 149 USD/Monat im Jahr 1, 529 USD/Monat im Jahr 2.
- OutSystems: Die “Free Tier” endet bei 100 Nutzern. Danach Enterprise-Vertrag ab 36’000 EUR/Jahr.
- Retool: Self-Hosted kostet 500 USD/Monat. Cloud-Version speichert Queries unverschlüsselt.
- Allgemein: Schulungskosten werden unterschätzt. Ein Team braucht 2-4 Wochen, um eine Low-Code-Plattform produktiv zu nutzen.
FAQs
Kann man eine No-Code-App später in echten Code umwandeln?
Praktisch nein. Keine der grossen Plattformen (Bubble, Glide, Softr) bietet einen brauchbaren Code-Export. “Migration” bedeutet: Anforderungen dokumentieren und neu bauen. Planen Sie 60-80% der Original-Entwicklungskosten ein.
Sind Low-Code-Plattformen sicher genug für Finanzdaten?
OutSystems und Mendix bieten SOC 2 und ISO 27001 Zertifizierungen. Aber: Sie kontrollieren nicht die Infrastruktur. Für Schweizer Finanzdienstleister, die der FINMA unterstehen, reicht das oft nicht. Die FINMA verlangt nachvollziehbare Datenverarbeitung, und bei einer Plattform, deren internes Verhalten Sie nicht auditieren können, wird das schwierig.
Lohnt sich Low-Code für ein MVP?
Ja, unter zwei Bedingungen: (1) Sie werfen den Prototyp danach weg und bauen die Produktionsversion sauber. (2) Sie verwenden maximal 4-6 Wochen darauf. Alles darüber ist kein Prototyp mehr.