Von der Idee zur App mit Low-Code und No-Code: der Praxisweg in sieben Schritten

Wie wird aus einer Idee eine funktionierende App, ohne dass ein Entwicklerteam sie von Grund auf programmiert – und wo hat dieser Weg seine Grenzen?

Angenommen, ein Haustechnik-Betrieb mit 60 Beschäftigten schreibt seine Wartungsprotokolle noch auf Papier. Die Monteure füllen vor Ort ein Formular aus, fotografieren den Heizkessel mit dem privaten Handy und geben am Freitag einen Stapel Zettel im Büro ab. Dort tippt jemand alles ab, sucht die passenden Fotos aus den Chatverläufen und schreibt die Rechnung. Die Idee liegt auf der Hand: eine App auf dem Diensthandy, die das Protokoll erfasst, Fotos anhängt und die Daten direkt ins Büro schickt. Die Frage ist nur, wie man von dieser Idee zu einer App kommt, die im Alltag wirklich funktioniert.

Die kurze Antwort: Mit einer Low-Code- oder No-Code-Plattform ist eine solche App heute in wenigen Wochen machbar, oft ohne eine Zeile klassischen Programmcode. Der Weg dorthin folgt sieben Schritten: Problem klären, Plattform wählen, Datenmodell anlegen, Prototyp bauen, mit echten Nutzern testen, Betrieb organisieren und Regeln für die Governance festlegen. Die Plattform ist dabei selten das Problem. Schiefgehen Projekte meist beim ersten und beim letzten Schritt – weil niemand genau weiß, was die App leisten soll, oder weil sich nach dem Start niemand um sie kümmert.

Die folgenden Abschnitte gehen diese Schritte der Reihe nach durch, zeigen, welche Plattform für welchen Zweck passt, was eine Low-Code-App kostet und wann klassische Softwareentwicklung die bessere Wahl bleibt.

Low-Code und No-Code in Kürze: was die Begriffe meinen

Beide Ansätze verfolgen dasselbe Ziel: Anwendungen entstehen in einer visuellen Entwicklungsumgebung statt im Code-Editor. Man zieht Bausteine wie Eingabefelder, Listen, Schaltflächen und Datenquellen auf eine Arbeitsfläche, verbindet sie und legt mit Regeln fest, was passieren soll („Wenn der Status auf erledigt steht, schicke eine E-Mail an das Büro“).

• Low-Code richtet sich an Entwickler und technisch versierte Fachleute. Der größte Teil der App entsteht visuell, an kniffligen Stellen lässt sich eigener Code ergänzen – etwa für eine spezielle Berechnung, eine Schnittstelle zu einem Altsystem oder eine eigene Oberflächenkomponente.
• No-Code richtet sich an Fachanwender ohne Programmierkenntnisse. Alles geschieht über Konfiguration und vorgefertigte Module. Das macht den Einstieg leicht, setzt aber engere Grenzen, sobald die Anforderungen ungewöhnlich werden.

Neu ist die Idee nicht. Schon Ende der 1980er- und Anfang der 1990er-Jahre versprachen Werkzeuge für Rapid Application Development (RAD) und Sprachen der vierten Generation (4GL), dass man beschreibt, was ein Programm tun soll, statt wie. Visual Basic machte es populär, Oberflächen per Drag-and-Drop zusammenzuklicken. Was heutige Plattformen davon unterscheidet, sind die Cloud, die fertigen Anschlüsse an Hunderte Dienste, die Ausrichtung auf Smartphone und Browser zugleich – und seit Kurzem KI-Assistenten, die aus einer Beschreibung in Alltagssprache einen ersten Entwurf erzeugen.

Wer die Grundlagen, Vor- und Nachteile ausführlicher nachlesen möchte, findet sie im Beitrag No-Code und Low-Code: Trend oder das nächste große Ding?. Hier geht es um die Praxis: Wie kommt man von der Idee zur App?

Schritt 1: Das Problem klären, bevor es um Werkzeuge geht

Der häufigste Fehler ist, mit der Plattform anzufangen. Jemand hat ein Video über Power Apps gesehen, probiert es aus und baut drauflos. Nach drei Wochen gibt es eine App mit zwölf Bildschirmen, die niemand benutzt, weil sie das eigentliche Problem nicht löst. Besser ist eine Stunde mit Papier und Stift und drei Fragen:

• Wer nutzt die App, wo und wie oft? Ein Monteur im Heizungskeller mit Handschuhen und schlechtem Netz braucht große Schaltflächen und einen Offline-Modus. Eine Sachbearbeiterin am Schreibtisch braucht Tabellen, Filter und Tastaturbedienung.
• Welcher Ablauf soll sich ändern – und woran merkt man den Erfolg? „Protokolle sind am selben Tag im Büro statt am Freitag“ ist ein messbares Ziel. „Digitaler werden“ ist keines.
• Welche Daten gibt es schon, und wo liegen sie? Kundenstamm im ERP-System, Anlagenliste in Excel, Termine im Outlook-Kalender: Jede dieser Quellen entscheidet mit darüber, welche Plattform später passt.

Hilfreich ist eine Liste mit höchstens fünf Muss-Funktionen für die erste Version. Alles andere kommt auf eine Wunschliste für später. Low-Code lebt davon, dass man klein anfängt und schnell nachbessert. Wer gleich das komplette Wunschpaket umsetzen will, verliert genau diesen Vorteil. Wie man Anforderungen sauber herausarbeitet, ohne in Pflichtenheften zu versinken, ist eine eigene Disziplin – sie lohnt sich auch bei kleinen Apps.

In diesem Schritt fällt auch eine Vorentscheidung: Braucht es überhaupt eine App? Manchmal reicht ein gutes Formular mit einer automatischen Weiterleitung, manchmal eine gemeinsam genutzte Liste. Eine App ist dann sinnvoll, wenn mehrere Menschen regelmäßig mit denselben Daten arbeiten, unterschiedliche Rollen haben und der Ablauf aus mehreren Stationen besteht.

Schritt 2: Die passende Plattform wählen

Der Markt ist groß und unübersichtlich. Hilfreich ist es, die Angebote nach ihrem Schwerpunkt zu sortieren. Die folgenden Gruppen und Beispiele geben den Stand vom Herbst 2026 wieder; Funktionsumfang und Preise ändern sich bei allen Anbietern regelmäßig.

Microsoft Power Apps: naheliegend für Microsoft-365-Unternehmen

Power Apps gehört zur Microsoft Power Platform, zusammen mit Power Automate für Abläufe und Power BI für Auswertungen. Der große Vorteil liegt in der Nähe zu dem, was viele Unternehmen ohnehin nutzen: Anmeldung über das bestehende Microsoft-Konto, Daten aus SharePoint-Listen, Excel-Tabellen oder dem Datenspeicher Dataverse, Einbindung in Teams. Für interne Apps in Unternehmen, die ihren Arbeitsplatz auf Microsoft 365 aufgebaut haben, ist Power Apps meist die erste Plattform, die man prüfen sollte. Mit Copilot lässt sich eine App inzwischen aus einer Beschreibung in Alltagssprache entwerfen; das Ergebnis ist ein Startpunkt, kein fertiges Produkt.

Mendix und OutSystems: für größere Anwendungen mit IT-Beteiligung

Mendix und OutSystems sind klassische Low-Code-Plattformen für Unternehmensanwendungen. Sie richten sich an Entwicklerteams und an Fachbereiche, die eng mit der IT zusammenarbeiten. Ihre Stärken liegen bei komplexeren Datenmodellen, Schnittstellen zu ERP-Systemen wie SAP, sauberer Versionsverwaltung mit Test- und Produktivumgebungen und dem Betrieb vieler Anwendungen nebeneinander. Mendix gehört seit 2018 zu Siemens und wird dort auch für industrielle Anwendungen eingesetzt. Beide Anbieter haben KI-Assistenten in ihre Entwicklungsumgebungen eingebaut, die Logik vorschlagen oder Fehler erklären.

Bubble, Glide und andere: für Web-Apps und Gründer

Bubble ist eine No-Code-Plattform für vollwertige Web-Anwendungen mit eigener Datenbank, Benutzerkonten und Anbindung an Zahlungsdienste; inzwischen lassen sich damit auch Apps für iOS und Android bauen. Viele Gründerinnen und Gründer bauen damit ein erstes Produkt, um eine Geschäftsidee am Markt zu testen, bevor sie in eigene Entwicklung investieren. Glide und ähnliche Werkzeuge machen aus einer Excel- oder Google-Sheets-Tabelle in wenigen Stunden eine einfache App für Smartphone und Browser – ideal für kleine Teams und überschaubare Abläufe.

Datenbank-Werkzeuge: Airtable, Ninox, Oracle APEX und Joget

Eine eigene Gruppe bilden Werkzeuge, die von der Datenbank her denken. Airtable verbindet Tabellenkalkulation und Datenbank, Ninox stammt aus Berlin, speichert die Daten in Deutschland und wird oft als Ersatz für gewachsene Excel- und Access-Lösungen genutzt. Oracle APEX richtet sich an Unternehmen, deren Daten ohnehin in einer Oracle-Datenbank liegen, und ist dort ohne Aufpreis enthalten; Joget ist eine Plattform für Formulare und Workflows, deren Community Edition Open Source ist und die sich auch im eigenen Rechenzentrum betreiben lässt.

Woran Sie die Auswahl festmachen

• Vorhandene Landschaft: Wo liegen Ihre Daten, welche Anmeldung nutzen Ihre Beschäftigten? Eine Plattform, die dazu passt, spart Wochen an Schnittstellenarbeit.
• Wer baut und wer pflegt: No-Code für Fachanwender, Low-Code, wenn Entwickler beteiligt sind oder es werden sollen.
• Zielgerät: Browser, Smartphone, Tablet im Lager? Brauchen Sie Kamera, GPS, Barcode-Scanner, Offline-Betrieb?
• Datenschutz und Hosting: In welchem Land liegen die Daten, gibt es einen Auftragsverarbeitungsvertrag nach DSGVO, lassen sich Rechenzentren in der EU wählen?
• Ausstieg: Lassen sich Daten und Logik exportieren? Was passiert, wenn der Anbieter Preise erhöht oder das Produkt einstellt?
• Lizenzmodell: Zahlen Sie pro Nutzer, pro App, pro Ausführung oder nach Datenmenge? Das entscheidet mehr über die Kosten als der Einstiegspreis.

Die Frage nach dem Ausstieg ist keine Theorie. Amazon stellte seine No-Code-Plattform Honeycode, die noch als Beta lief, Ende Februar 2024 ein; wer darauf Apps gebaut hatte, musste umziehen. Der Fall zeigt, warum die Abhängigkeit vom Anbieter zu den größten Risiken von Low-Code gehört.

Schritt 3: Das Datenmodell zuerst – der unterschätzte Teil

Die Oberfläche einer App ist schnell gebaut. Was über Erfolg oder Frust entscheidet, liegt darunter: das Datenmodell, also die Frage, welche Dinge die App verwaltet und wie sie zusammenhängen. Im Beispiel des Haustechnik-Betriebs sind das Kunden, Anlagen, Wartungstermine, Protokolle und Fotos. Ein Kunde hat mehrere Anlagen, eine Anlage hat viele Wartungen, jede Wartung hat ein Protokoll mit mehreren Fotos.

Wer das nicht vorher aufschreibt, landet schnell bei einer einzigen großen Tabelle, in der die Kundenadresse in jeder Zeile neu steht. Das funktioniert bei zwanzig Einträgen, wird aber bei zweitausend unübersichtlich und fehleranfällig: Zieht ein Kunde um, muss man hundert Zeilen ändern. Drei Faustregeln helfen auch Laien:

• Jede Sache, die eigene Eigenschaften hat (Kunde, Anlage, Termin), bekommt eine eigene Tabelle.
• Verknüpfungen statt Kopien: Das Protokoll verweist auf die Anlage, statt deren Daten zu wiederholen.
• Auswahllisten statt Freitext, wo immer es geht – „Status: offen, in Arbeit, erledigt“ lässt sich auswerten, „ist so gut wie fertig“ nicht.

Hier fällt auch die Entscheidung, wo die Daten liegen: in der Plattform selbst (etwa Dataverse bei Microsoft), in einer vorhandenen Datenbank oder in einem führenden System wie dem ERP, aus dem die App nur liest und in das sie zurückschreibt. Für personenbezogene Daten gilt die DSGVO unabhängig davon, ob eine App mit Low-Code oder klassisch entwickelt wurde: Zweck festlegen, nur Nötiges speichern, Zugriffe beschränken, Löschfristen definieren.

Schritt 4: Ein Prototyp in Tagen statt Monaten

Jetzt spielt Low-Code seine Stärke aus. Ein erster klickbarer Prototyp mit echten Bildschirmen und Testdaten entsteht oft in wenigen Tagen. Er muss nicht schön sein, aber er muss den Kernablauf zeigen: Termin öffnen, Anlage auswählen, Prüfpunkte abhaken, Foto aufnehmen, abschicken.

KI-Assistenten beschleunigen diesen Schritt spürbar. Bei Power Apps, Mendix, OutSystems und anderen beschreibt man die gewünschte App in einem Satz, und die Plattform schlägt Tabellen, Bildschirme und Formulare vor. Das spart Fleißarbeit. Überschätzt wird allerdings, wie viel davon ohne Nacharbeit trägt. Die KI kennt Ihren Betrieb nicht; sie weiß nicht, dass bei Gasthermen andere Prüfpunkte gelten als bei Wärmepumpen. Der Entwurf ist ein Gerüst, das jemand mit Fachwissen prüfen und umbauen muss.

Wichtig ist, den Prototyp früh den späteren Nutzern zu zeigen – nicht als Präsentation, sondern in die Hand gegeben. Zehn Minuten, in denen ein Monteur versucht, ein Protokoll anzulegen, sagen mehr als jede Anforderungsliste. Was er sucht, wo er zögert, welche Felder er überspringt: Das sind die Hinweise für die nächste Runde. Genau dieser schnelle Wechsel aus Bauen und Ausprobieren ist der eigentliche Vorteil gegenüber klassischen Projekten, bei denen die Fachabteilung das Ergebnis oft erst nach Monaten zu sehen bekommt.

Schritt 5: Testen mit echten Nutzern und echten Daten

Ein Prototyp, der mit fünf Testkunden funktioniert, ist noch keine belastbare App. Vor dem Start gehören einige Prüfungen dazu, die bei Low-Code gern übersprungen werden, weil alles so leicht aussieht:

• Datenmenge: Wie verhält sich die App mit dem echten Bestand – 3.000 Anlagen statt 30? Manche Plattformen laden Listen nur bis zu einer bestimmten Zahl von Einträgen, wenn man die Abfragen nicht passend baut – bei Power Apps sind es standardmäßig 500.
• Rollen und Rechte: Sieht der Monteur nur seine eigenen Termine? Kann eine Aushilfe versehentlich Kundendaten löschen?
• Grenzfälle: Was passiert ohne Netz, bei abgebrochenem Upload, bei doppelt angelegten Kunden?
• Bedienbarkeit: Ein Pilotteam von drei bis fünf Personen nutzt die App zwei Wochen lang im echten Alltag, parallel zum alten Verfahren.

Größere Plattformen bieten getrennte Umgebungen für Entwicklung, Test und Produktivbetrieb. Diese Trennung sollten Sie auch bei kleinen Apps nutzen: Wer direkt in der App ändert, mit der zwanzig Kollegen gerade arbeiten, testet am lebenden Objekt. Sicherheit ist dabei kein Thema nur für die IT. Weil die Entwicklung auf der Plattform eines Anbieters läuft, hängt ein Teil der Sicherheit von dessen Schutzmaßnahmen ab – der andere Teil davon, wie sorgfältig die App gebaut ist. Falsch gesetzte Freigaben sind bei Low-Code-Apps eine typische Schwachstelle.

Schritt 6: Betrieb – wer kümmert sich nach dem Start?

Am Tag des Starts beginnt die eigentliche Arbeit. Eine App, die im Alltag genutzt wird, braucht jemanden, der sie verantwortet. Drei Fragen sollten vor dem Start beantwortet sein:

• Wer ist Ansprechpartner, wenn etwas nicht funktioniert – und wer vertritt diese Person im Urlaub?
• Wer entscheidet über Änderungswünsche? Nach dem Start kommen sie zuverlässig. Ohne Priorisierung wächst die App unkontrolliert.
• Was passiert bei Plattform-Updates? Die Anbieter verändern ihre Plattformen laufend, ändern Schnittstellen, stellen Funktionen ein oder ersetzen sie. Jemand sollte die Ankündigungen lesen und die App nach größeren Änderungen kurz prüfen.

Ein häufiges Muster: Eine engagierte Mitarbeiterin baut eine App, die zur Lebensader eines Teams wird. Dann wechselt sie die Stelle, und niemand weiß, wie die App funktioniert. Eine kurze Dokumentation – welche Tabellen, welche Abläufe, welche Zugänge – und eine zweite Person, die sich auskennt, verhindern das.

Schritt 7: Governance – damit aus vielen kleinen Apps kein Wildwuchs wird

Solange es eine App gibt, ist Governance kein Thema. Bei zwanzig Apps, gebaut von zwölf Personen in fünf Abteilungen, sieht das anders aus. Ohne Regeln entsteht eine Schatten-IT: Anwendungen, von denen die IT nichts weiß, die Kundendaten an Dienste außerhalb des Unternehmens schicken oder an denen wichtige Abläufe hängen, ohne dass jemand für Sicherungen sorgt.

Gute Governance bremst nicht, sie schafft einen sicheren Spielraum. Bewährt haben sich:

• Ein Verzeichnis aller produktiven Apps mit verantwortlicher Person, Zweck und Art der verarbeiteten Daten.
• Datenrichtlinien: Welche Anschlüsse dürfen kombiniert werden? Bei der Power Platform lassen sich solche Regeln zentral festlegen, etwa dass Daten aus dem ERP-System nicht an private Cloud-Speicher gehen dürfen.
• Stufen: Persönliche Helfer darf jeder bauen; Apps für ganze Abteilungen gehen vor dem Start durch einen kurzen Check; Apps mit sensiblen Daten oder für Kunden entstehen gemeinsam mit der IT.
• Eine Anlaufstelle, oft „Center of Excellence“ genannt: ein kleines Team, das berät, Vorlagen bereitstellt und die Regeln pflegt.

Wie sich die Rolle von IT-Abteilung und Entwicklern dabei verschiebt – vom Bauen hin zum Befähigen, Absichern und Integrieren –, beschreibt der Beitrag Die Zukunft der Softwareentwicklung mit Low-Code-Plattformen.

Was eine Low-Code-App kostet

„Kostenlos starten“ steht bei fast jedem Anbieter auf der Startseite. Für den Produktivbetrieb gilt das selten. Die Kosten setzen sich aus drei Teilen zusammen:

• Lizenzen: Die meisten Plattformen rechnen pro Nutzer und Monat ab, manche pro App, nach Ausführungen oder nach Datenmenge. Bei Microsoft sind einfache Apps auf Basis von SharePoint und Excel in vielen Microsoft-365-Lizenzen enthalten. Sobald eine App Dataverse oder sogenannte Premium-Anschlüsse nutzt – etwa zu SQL-Datenbanken oder SAP –, braucht jeder Nutzer eine Premium-Berechtigung: meist die Lizenz Power Apps Premium oder eine nutzungsabhängige Abrechnung je App über Azure. Größere Plattformen wie Mendix und OutSystems haben kostenlose Einstiegsversionen; für den Produktivbetrieb richtet sich der Preis nach Umfang und Zahl der Apps, Nutzern und Zusatzleistungen, genaue Konditionen gibt es meist erst im Angebot.
• Interne Arbeitszeit: Auch wenn niemand programmiert, kostet die App Zeit – für Anforderungen, Bau, Tests, Schulung und Pflege. Für eine überschaubare App wie das Wartungsprotokoll sind einige Personentage bis wenige Wochen realistisch.
• Externe Unterstützung: Schulung, Beratung oder Entwicklung von Schnittstellen, falls im eigenen Haus das Wissen fehlt.

Die Lizenzfrage verdient besondere Aufmerksamkeit, weil sie mit der Zahl der Nutzer wächst. Eine App für acht Personen im Büro ist günstig; dieselbe App für 400 Beschäftigte, die sie zweimal im Monat öffnen, kann teurer werden als eine klassisch entwickelte Webanwendung. Rechnen Sie deshalb vor der Plattformwahl ein realistisches Szenario für drei Jahre durch – mit den Nutzerzahlen, die Sie erwarten, wenn die App erfolgreich ist.

Ein Beispielprojekt durchgespielt: die Wartungsprotokoll-App

Wie die sieben Schritte zusammenspielen, zeigt das Beispiel vom Anfang. Angenommen, der Haustechnik-Betrieb arbeitet mit Microsoft 365, die Kundendaten liegen in einer Branchensoftware mit Exportfunktion, die Anlagenliste in Excel.

1. Problem: Protokolle sollen am selben Tag im Büro sein, Fotos automatisch am richtigen Auftrag hängen, die Rechnung ohne Abtippen entstehen. Muss-Funktionen: Termine des Tages anzeigen, Protokoll ausfüllen, Fotos aufnehmen, Unterschrift des Kunden, Übermittlung.
2. Plattform: Power Apps, weil Anmeldung, Diensthandys und Teams schon vorhanden sind. Für die Weiterleitung ans Büro sorgt Power Automate.
3. Datenmodell: Tabellen für Kunden, Anlagen, Termine, Protokolle und Fotos; Prüfpunkte als Auswahllisten je Anlagentyp.
4. Prototyp: Nach einer Woche zeigt der Entwurf die Tagesliste und ein Protokollformular. Der erste Test im Heizungskeller zeigt: Die Schaltflächen sind zu klein, und ohne Netz geht nichts.
5. Test: Drei Monteure nutzen die App zwei Wochen lang parallel zum Papier. Ergebnis: Offline-Speicherung wird nachgerüstet, zwei Prüfpunkte fehlen, die Unterschrift wird als Bild gespeichert.
6. Betrieb: Die Büroleiterin verantwortet die App, ein Kollege vertritt sie. Änderungswünsche landen in einer Liste, über die einmal im Monat entschieden wird.
7. Governance: Die App steht im Verzeichnis, Kundendaten bleiben im Microsoft-Mandanten des Betriebs, der Datenschutzbeauftragte hat die Verarbeitung geprüft.

Realistisch ist ein solches Projekt in sechs bis zehn Wochen bis zum Regelbetrieb, mit einem Bruchteil der Arbeitszeit einer Person. Klassisch entwickelt wäre es kaum schneller gegangen, aber deutlich teurer und abhängiger von einem externen Dienstleister.

Wofür Unternehmen Low-Code und No-Code einsetzen

Die Wartungsprotokoll-App steht für eine ganze Gruppe typischer Anwendungen. Gut geeignet sind Vorhaben, bei denen Daten erfasst, weitergegeben, genehmigt und ausgewertet werden:

• Interne Werkzeuge und Dashboards: Urlaubsanträge, Materialbestellungen, Besucheranmeldung, Auswertungen für die Geschäftsführung.
• Kundenbeziehungen und Vertrieb: schlanke CRM-Lösungen für Teams, denen ein großes System zu schwerfällig ist, Angebotsfreigaben, Messekontakte.
• Mobile Anwendungen für den Außendienst und Kundenservice: Prüfprotokolle, Inventur, Schadensaufnahme mit Foto, Supportanfragen und Rückmeldungen von Kunden.
• Ablösung von Excel- und Access-Lösungen: gewachsene Tabellen, an denen mehrere Personen gleichzeitig arbeiten und die niemand mehr überblickt.
• Prototypen und erste Produktversionen (MVP): Gründer und Produktteams testen, ob eine Idee überhaupt Nutzer findet, bevor sie in eigene Entwicklung investieren.

Auch im privaten Umfeld und für Selbstständige hat sich No-Code etabliert: für Portfolio-Websites, Haushaltsbücher, Vereinsverwaltung oder die Planung von Veranstaltungen. Die Werkzeuge sind dieselben, die Anforderungen an Governance und Datenschutz deutlich geringer.

Weniger geeignet sind Anwendungen, die komplexe Berechnungen in großer Menge ausführen, sehr viele gleichzeitige Nutzer bedienen oder eine Oberfläche brauchen, die sich deutlich von den Bausteinen der Plattform unterscheidet. Damit sind wir bei der wichtigsten Abgrenzung.

Wann klassische Entwicklung die bessere Wahl ist

Low-Code ist kein Ersatz für Softwareentwicklung, sondern eine Abkürzung für bestimmte Aufgaben. Klassisch programmieren sollten Sie, wenn mindestens einer dieser Punkte zutrifft:

• Die App ist Ihr Produkt. Wer Software an Kunden verkauft, braucht volle Kontrolle über Code, Architektur, Kosten pro Nutzer und Weiterentwicklung. Die Abhängigkeit von einer Plattform wäre ein Geschäftsrisiko.
• Hohe Last oder besondere Leistung: Zehntausende gleichzeitige Nutzer, Echtzeitverarbeitung, rechenintensive Logik – hier stoßen viele Plattformen an technische oder wirtschaftliche Grenzen.
• Sehr individuelle Oberflächen: Wenn Gestaltung und Bedienung das Unterscheidungsmerkmal sind, kämpft man bei Low-Code ständig gegen die Vorgaben der Bausteine.
• Strenge Anforderungen an Betrieb und Prüfbarkeit: Wenn Code geprüft, eigene Sicherheitsprüfungen durchgeführt oder ein bestimmter Betriebsort vorgeschrieben ist, bieten nicht alle Plattformen die nötige Transparenz.
• Lange Lebensdauer mit vielen Nutzern: Über zehn Jahre und Hunderte Nutzer gerechnet, können Lizenzkosten eine Eigenentwicklung übersteigen.

Die Grenze verschiebt sich allerdings. KI-gestützte Programmierwerkzeuge machen auch die klassische Entwicklung schneller, und Low-Code-Plattformen werden leistungsfähiger. In vielen Unternehmen entsteht deshalb eine Mischform: Die IT stellt saubere Schnittstellen und Datenquellen bereit, Fachbereiche bauen darauf mit Low-Code ihre Anwendungen. Welche Werkzeuge und Plattformen es im Detail gibt, zeigt die Themenseite No-Code und Low-Code Plattformen.

Was das für Ihr Unternehmen bedeutet

Für die meisten mittelständischen Unternehmen lohnt sich Low-Code dort, wo heute Excel-Listen, Papierformulare und E-Mail-Ketten den Ablauf bestimmen. Hier ist der Nutzen schnell sichtbar, das Risiko überschaubar und die Lernkurve flach. Wer bereits mit Microsoft 365 arbeitet, hat mit der Power Platform einen naheliegenden Einstieg; wer größere, geschäftskritische Anwendungen plant, sollte Plattformen wie Mendix oder OutSystems gemeinsam mit der IT bewerten.

Überschätzt wird, wie viel die Plattform allein leistet. Die Zeitersparnis entsteht beim Bauen, nicht beim Nachdenken über Abläufe, Daten und Zuständigkeiten. Unterschätzt werden Lizenzkosten bei wachsender Nutzerzahl und der Aufwand für Betrieb und Governance. Die KI-Assistenten der Plattformen verkürzen den Weg zum ersten Entwurf erheblich, ersetzen aber weder Fachwissen noch Tests.

Der Markt wird sich weiter bewegen: Anbieter werden zusammengehen oder verschwinden, Funktionen wandern zwischen Produkten, Preise ändern sich. Wer sein Datenmodell sauber aufbaut, Daten in einem eigenen, exportierbaren Speicher hält und die Abhängigkeit von einzelnen Funktionen begrenzt, bleibt beweglich. Meine Empfehlung: Beginnen Sie mit einem konkreten, ärgerlichen Ablauf, bauen Sie eine kleine App in wenigen Wochen, und legen Sie die Regeln für Betrieb und Governance fest, bevor die zweite und dritte App entstehen.

Häufige Fragen zur App-Entwicklung mit Low-Code und No-Code

Wie lange dauert es von der Idee bis zur fertigen App?

Ein klickbarer Prototyp entsteht oft in wenigen Tagen. Bis zum stabilen Regelbetrieb mit Tests, Schulung und geklärten Zuständigkeiten vergehen bei einer überschaubaren internen App meist einige Wochen. Größere Unternehmensanwendungen mit mehreren Schnittstellen brauchen Monate – aber in der Regel deutlich weniger als ein klassisches Projekt gleichen Umfangs.

Brauche ich Programmierkenntnisse?

Für No-Code-Werkzeuge nicht. Hilfreich sind aber ein Grundverständnis für Daten und Tabellen, logisches Denken in „Wenn – dann“-Regeln und Sorgfalt beim Testen. Bei Low-Code-Plattformen wie Power Apps hilft es, die Formelsprache zu lernen, die an Excel-Formeln angelehnt ist.

Kann ich mit No-Code eine App für den App Store bauen?

Einige Plattformen erzeugen Apps, die sich in den App Store von Apple und in Google Play einreichen lassen; andere liefern Web-Apps, die im Browser laufen und sich auf dem Startbildschirm ablegen lassen. Für interne Apps reicht die zweite Variante meist aus. Wer eine App öffentlich für Kunden anbieten will, sollte genau prüfen, welche Gerätefunktionen die Plattform unterstützt und welche Kosten pro Nutzer anfallen.

Gehören mir die App und die Daten?

Die Daten in der Regel ja, sofern sie sich exportieren lassen – das sollten Sie vor der Wahl prüfen. Die App selbst existiert dagegen meist nur innerhalb der Plattform. Ein Umzug zu einem anderen Anbieter bedeutet fast immer einen Neubau der Oberfläche und der Logik.

Ist Low-Code sicher genug für personenbezogene Daten?

Die großen Plattformen bieten Auftragsverarbeitungsverträge, feine Rechteverwaltung und Rechenzentren in der EU – bei manchen Anbietern allerdings nur in bestimmten Tarifen. Ob eine App sicher ist, hängt aber vor allem davon ab, wie sie gebaut ist: welche Rollen welche Daten sehen, welche Anschlüsse erlaubt sind und ob jemand die Freigaben prüft. Bei sensiblen Daten gehören IT und Datenschutzbeauftragte von Anfang an dazu.

Wie lerne ich Power Apps oder eine andere Plattform am schnellsten?

Am besten an einem echten, kleinen Vorhaben aus dem eigenen Alltag statt an Übungsbeispielen. Die Hersteller bieten kostenlose Lernpfade; eine Schulung mit Praxisteil spart Zeit bei Datenmodell, Formeln und Berechtigungen, wo die meisten Einsteiger hängen bleiben.

Wer den Einstieg mit Microsoft gehen möchte, kann im Seminar Microsoft Power Apps Grundlagen an einem eigenen Beispiel üben – von der Datenquelle über die Oberfläche bis zur Freigabe im Team.