No-Code-Werkzeuge versprechen Anwendungen ohne klassische Programmierung. Das kann kleinen Teams helfen, Formulare, Freigaben oder interne Übersichten schneller umzusetzen. Gleichzeitig bleibt jede Anwendung ein System mit Daten, Regeln, Zugängen und möglichen Fehlern. Dass Bausteine per Maus verbunden werden, hebt Verantwortung nicht auf.

Ein sinnvoller Einstieg beginnt mit einem begrenzten, reversiblen Prozess. Er hat wenige Beteiligte, überschaubare Daten und eine manuelle Alternative. Kritische Entscheidungen, sensible Informationen und komplexe Integrationen verlangen deutlich mehr Prüfung oder eine andere technische Lösung.

Kurz gesagt: Beschreibe zuerst Ablauf und Risiko. Wähle einen kleinen Anwendungsfall, bestimme fachliche und technische Eigentümerschaft und prüfe Datenschutz, Rollen, Export und Kosten. Teste mit repräsentativen Fällen. Eine No-Code-Anwendung geht erst in Betrieb, wenn Überwachung, Änderung und Abschaltung geregelt sind.

Was No-Code tatsächlich verändert

No-Code verlagert Arbeit. Weniger Quellcode bedeutet mehr Konfiguration, Datenmodellierung und Prozessentscheidung durch Fachbereiche. Die Anwendung muss weiterhin verstehen, wer etwas darf, welche Daten gültig sind und was bei einem Fehler geschieht.

Die Plattform übernimmt meist Laufzeit, Oberflächenbausteine und bestimmte Sicherheitsfunktionen. Dein Unternehmen bleibt für Auswahl, Konfiguration, Zugänge, Inhalte und Geschäftsprozess verantwortlich. Eine sichere Plattform kann durch zu breite Freigaben unsicher genutzt werden.

Dokumentiere die Anwendung wie andere Systeme: Zweck, Eigentümer, Daten, Rollen, Verbindungen, Änderungen und Notfallweg. „Hat jemand aus dem Team gebaut“ ist keine Betriebsbeschreibung.

Geeignete erste Anwendungsfälle

Gut geeignet sind häufig interne, begrenzte Abläufe: eine Geräteausgabe dokumentieren, Verbesserungsvorschläge sammeln, Freigaben koordinieren oder einen bestehenden Tabellenprozess mit klaren Regeln ersetzen.

Der Prozess sollte häufig genug vorkommen, damit die Verbesserung nützt, aber nicht so kritisch sein, dass ein kurzer Ausfall das Kerngeschäft stoppt. Eine manuelle Fortsetzung muss möglich bleiben.

Wähle Fälle mit wenigen Datenquellen. Jede Schnittstelle erhöht Abhängigkeit und Fehlerbilder. Eine kleine Anwendung mit einem klaren Formular und einer Liste ist für den Einstieg lehrreicher als ein selbstgebautes Mini-ERP.

Fälle, die mehr Vorsicht brauchen

Lohn, Gesundheit, Bewerbungen, Kreditentscheidungen oder umfangreiche Kundendaten können besondere rechtliche und sicherheitsbezogene Anforderungen haben. Hier genügt keine spontane Fachbereichslösung. Datenschutz, Informationssicherheit, Recht und gegebenenfalls Arbeitnehmervertretung müssen früh beteiligt sein.

Auch ein öffentliches Kundenportal ist kein harmloser Start. Anmeldung, Missbrauchsschutz, Barrierefreiheit, Verfügbarkeit und sichere Entwicklung verlangen Fachwissen. Gleiches gilt für Anwendungen, die Zahlungen oder Produktionsanlagen steuern.

Automatisierte Entscheidungen mit erheblichen Folgen brauchen eine genaue fachliche und rechtliche Prüfung. Ein visueller Regelbaustein kann ebenso diskriminierende oder falsche Logik enthalten wie klassischer Code.

Den Prozess vor dem Werkzeug klären

Zeichne Auslöser, Eingaben, Entscheidungen, Ergebnis und Ausnahmen. Wer gibt Daten ein? Wer darf freigeben? Wann ist ein Vorgang abgeschlossen? Was passiert bei Ablehnung oder fehlender Information?

Entferne unnötige Schritte, bevor du sie digital abbildest. Eine Automatisierung macht eine unklare Freigabe schneller unklar. Wenn drei Personen dieselbe Sache prüfen, kläre den Grund.

Definiere ein messbares Ziel: weniger doppelte Eingabe, kürzere Durchlaufzeit oder vollständiger Status. „Wir wollen No-Code nutzen“ ist kein Prozessziel.

Daten und Datenschutz

Liste Datenfelder und Zwecke. Sammle nicht vorsorglich alles, was der Formularbaukasten anbietet. Personenbezogene Daten benötigen eine geklärte Rechtsgrundlage, transparente Information, angemessene Aufbewahrung und Schutz.

Prüfe Anbieter, Speicherorte, Unterauftragnehmer und Verträge. Eine Plattform kann verschiedene Tarife und Regionen haben; die Marketing-Startseite beschreibt nicht zwingend deine konkrete Konfiguration.

Lege Löschung und Export fest. Was geschieht nach Abschluss eines Vorgangs? Werden Anhänge wirklich entfernt? Können Betroffenenrechte umgesetzt werden? Datenschutz muss im Datenmodell funktionieren.

Rollen und Zugänge

Nutze persönliche Konten und zentrale Anmeldung, wenn verfügbar. Gemeinsame Passwörter verhindern Nachvollziehbarkeit. Mehrfaktor-Authentisierung schützt besonders administrative Rollen.

Trenne Entwickeln, Freigeben und Nutzen. Nicht jede Person, die Datensätze bearbeiten darf, sollte Regeln oder Verbindungen ändern können. Prüfe Rollen mit Testkonten statt nur anhand ihrer Bezeichnung.

Plane Eintritt und Austritt. Zugänge werden regelmäßig überprüft und bei Rollenwechsel angepasst. Öffentliche Freigabelinks benötigen Ablauf, Schutz und eine bewusste Entscheidung.

Datenmodell statt großer Tabelle

Definiere eindeutige Vorgangsnummer, Status und Pflichtfelder. Verwende Auswahllisten nur für stabile Kategorien. Freitext ist flexibel, aber schwer auszuwerten und kann unerwartete sensible Informationen enthalten.

Trenne Stammdaten und Vorgänge. Kopiere Kundendaten nicht in jede Zeile, wenn eine referenzierte, kontrollierte Quelle möglich ist. Gleichzeitig darf eine Änderung historischer Stammdaten nicht unbemerkt alte Vorgänge verfälschen.

Lege Validierungen fest: Datum, Betrag, zulässiger Übergang. Eine freundliche Oberfläche verhindert keine fachlich unmöglichen Daten, wenn Regeln fehlen.

Automatisierungen kontrolliert aufbauen

Beginne mit Benachrichtigung oder klarer Statusänderung. Komplexe Ketten über mehrere Dienste sind schwerer zu testen. Jede Aktion benötigt eine eindeutige Kennung, damit Wiederholung nicht doppelte E-Mails, Rechnungen oder Datensätze erzeugt.

Behandle Fehler sichtbar. Wenn eine Verbindung ausfällt, landet der Vorgang in einer überwachten Liste. „Der Workflow ist gelaufen“ darf nicht bedeuten, dass niemand weiß, ob das Zielsystem die Daten angenommen hat.

Begrenze Wiederholungen und Nachrichten. Eine fehlerhafte Regel kann sonst in kurzer Zeit Tausende Aktionen auslösen. Kosten- und Mengenlimits gehören zum Schutz.

Schnittstellen und Geheimnisse

Verwende dokumentierte Schnittstellen und eigene technische Konten mit minimalen Rechten. API-Schlüssel gehören in vorgesehene geschützte Speicher, nicht in sichtbare Textfelder oder Anleitungen.

Prüfe Limits, Versionen und Fehlercodes. Eine erfolgreiche Verbindung im Test garantiert keinen stabilen Betrieb. Plane Änderungen und informiere Verantwortliche, wenn ein Anbieter eine Schnittstelle abkündigt.

Dokumentiere Richtung und Zweck jeder Datenübertragung. Bei Abschaltung muss klar sein, welche Verbindungen beendet und Schlüssel widerrufen werden.

Testen mit echten Fällen, nicht echten Geheimnissen

Erstelle repräsentative Testdaten ohne unnötige reale personenbezogene Informationen. Teste Standardfall, fehlende Eingabe, Ablehnung, doppelte Übermittlung, Rollenfehler und Ausfall einer Schnittstelle.

Lass künftige Nutzende Aufgaben ohne Anleitung durchführen. Beobachte, ob Status und Fehlermeldungen verständlich sind. Eine Anwendung, die nur die erstellende Person bedienen kann, ist noch nicht fertig.

Prüfe mobile Darstellung und Barrierefreiheit, wenn das Nutzungsszenario dies verlangt. Formlabels, Tastaturbedienung und verständliche Fehler sind auch bei internen Werkzeugen wichtig.

Versionen und Änderungen

Produktive Änderungen brauchen einen kleinen Freigabeprozess. Dokumentiere Anlass, erwartete Wirkung, Test und Rückweg. Nutze getrennte Test- und Produktionsumgebungen, soweit Plattform und Risiko dies erfordern.

Eine Änderung am Datenfeld kann Automatisierungen und Berichte brechen. Prüfe abhängige Komponenten vor Veröffentlichung. Ein Versionshinweis in einem Chat ersetzt keine nachvollziehbare Dokumentation.

Halte die Anwendung klein. Neue Wünsche werden gegen Zweck und Risiko geprüft. Wenn immer mehr kritische Funktionen hinzukommen, ist möglicherweise eine professionelle Neuentwicklung oder Standardsoftware geeigneter.

Kosten realistisch rechnen

Berücksichtige Konten, Automatisierungsläufe, Speicher, Schnittstellen, Support und höhere Tarife für Rollen oder Sicherheit. Ein günstiger Einstieg kann bei wachsender Nutzung deutlich teurer werden.

Interne Bau- und Pflegezeit gehört in die Rechnung. Fachkräfte benötigen Schulung und Freiraum. Wenn eine Anwendung nur in Überstunden gepflegt wird, ist das kein nachhaltiger Kostenvorteil.

Vergleiche mit bestehender Software und Prozessvereinfachung. Manchmal löst eine zusätzliche Funktion in einem bereits betriebenen System das Problem besser als eine neue Plattform.

Eigentümerschaft und Vertretung

Jede Anwendung bekommt eine fachliche Eigentümerin und eine technische Ansprechperson. Die fachliche Rolle verantwortet Prozess und Datenqualität; die technische Rolle Plattform, Zugänge und Betrieb.

Dokumentiere Vertretung. Urlaub oder Stellenwechsel dürfen das System nicht unwartbar machen. Vermeide persönliche Anbieteraccounts für betriebliche Anwendungen.

Führe ein zentrales Verzeichnis aller No-Code-Anwendungen. Enthalten sind Zweck, Kritikalität, Daten, Eigentümer, Kosten, letzte Prüfung und geplanter Lebenszyklus.

Export und Abschaltung

Teste den Datenexport vor dem Start. Enthält er Anhänge, Beziehungen, Zeitstempel und Status? Ist das Format ohne Plattform nutzbar? Ein sichtbarer CSV-Button beantwortet nicht jede Frage.

Definiere, wie lange die Anwendung betrieben wird und wann sie überprüft wird. Temporäre Lösungen erhalten ein Enddatum. Ohne diese Entscheidung werden sie leicht zu dauerhaften kritischen Systemen.

Bei Abschaltung exportierst und prüfst du benötigte Daten, beendest Automatisierungen, widerrufst Schlüssel, entfernst Konten und löschst Daten nach dem festgelegten Konzept. Der Vertrag wird erst beendet, wenn der Übergang gesichert ist.

Pilot mit klarer Grenze

Wähle fünf bis zehn Nutzende und einen Prozess. Der Pilot dauert beispielsweise vier Wochen und hat drei Kriterien: weniger Bearbeitungszeit, vollständiger Status und keine kritischen Fehler.

Sammelt Rückfragen und manuelle Korrekturen. Zählt nicht nur abgeschlossene Vorgänge. Eine schnelle App kann im Hintergrund zusätzliche Nacharbeit erzeugen.

Nach dem Pilot gibt es eine ausdrückliche Entscheidung: übernehmen, überarbeiten oder abschalten. „Läuft irgendwie weiter“ ist kein vierter Status.

Sicherheit in der Beschaffung

Prüfe Sicherheitsfunktionen, Nachweise, Support und Reaktion auf Schwachstellen. Das BSI stellt für Auftraggeber von Webanwendungen Anforderungen und Qualitätsprüfungen über Entwicklungsphasen bereit; die Grundidee gilt auch hier: Sicherheit wird als überprüfbare Anforderung beauftragt, nicht nur als Produktversprechen akzeptiert. Quelle: BSI – Leitfaden für Auftraggeber sicherer Webanwendungen.

Verlasse dich nicht allein auf Zertifikate. Prüfe den konkreten Dienst, Tarif und Verantwortungsbereich. Viele Schutzmaßnahmen müssen vom Kunden konfiguriert werden.

Plane Vorfälle: Kontaktweg, Datenexport, Zugriffsprotokolle und interne Entscheidung. Eine Anwendung ohne Notfallansprechperson gehört nicht in einen kritischen Prozess.

Dein nächster Schritt

Sammle fünf manuelle Abläufe und bewerte sie nach Häufigkeit, Kritikalität, Datenempfindlichkeit, Zahl der Schnittstellen und vorhandener Alternative. Wähle den häufigen, aber wenig kritischen Fall mit überschaubaren Daten. Zeichne ihn vollständig, bevor du eine Plattform öffnest.

Quellen und Prüfdatum

Geprüft am 21. September 2026: BSI-Leitfaden zur Entwicklung sicherer Webanwendungen für Auftraggeber. Datenschutz, Mitbestimmung, Sicherheit und rechtliche Anforderungen müssen für den konkreten Prozess und Anbieter individuell geprüft werden.