Apps und Websites mit KI bauen: was heute realistisch ist
Was sich tatsächlich geändert hat
Der Entwurf von Quelltext ist billig geworden. Was früher Tage dauerte – ein Formular, eine Auswertung, eine Schnittstelle – entsteht heute in Stunden, oft im Gespräch mit einem Modell. Das ist keine Werbung, das ist der Stand.
Was sich nicht geändert hat: alles, was nach dem Entwurf kommt. Betrieb, Sicherheit, Rechte, Sicherungen, Fehlersuche, Wartung. In einem Softwareprojekt war das Schreiben des Quelltextes noch nie der größte Posten; er ist jetzt nur noch kleiner geworden. Wer die Ersparnis mit der Gesamtersparnis verwechselt, plant falsch.
Die ehrliche Zusammenfassung lautet: Der Weg zum ersten Lauffähigen ist kurz geworden, der Weg zum Betriebsfähigen nicht.
Drei Arten von Vorhaben, drei Antworten
Das interne Werkzeug. Ein Rechner für Angebotspreise, eine Übersicht über Wartungstermine, ein Formular, das bisher eine Tabelle war. Wenige Nutzer, bekannte Daten, überschaubarer Schaden im Fehlerfall. Hier ist der Gewinn am größten und das Risiko am kleinsten – fangen Sie hier an, auch wenn es unspektakulär ist.
Der Prototyp. Etwas, das eine Idee zeigen soll: eine Oberfläche für ein Angebot, ein Entwurf für ein Produkt, ein Testlauf mit Kunden. In Tagen machbar, und als Entscheidungsgrundlage unbezahlbar – man sieht an einem lauffähigen Entwurf in zehn Minuten mehr als an einem Konzept in zehn Seiten. Wichtig ist nur, dass alle wissen, dass es ein Prototyp ist.
Das Produkt. Etwas, das Kunden benutzen, das Daten verarbeitet und das in drei Jahren noch laufen muss. Hier gelten unverändert die Regeln des Handwerks: Architektur, Tests, Rechte, Protokolle, Sicherungen, Wartung, jemand mit Bereitschaft. KI beschleunigt die Arbeit, sie ersetzt die Rolle nicht.
Die vier Fragen vor dem ersten Prototyp
Wessen Daten sind das? Eigene Betriebsdaten sind das eine, Kundendaten das andere, personenbezogene Daten das dritte. Diese Frage entscheidet über fast alles, was danach kommt – siehe DSGVO und KI.
Wer betreibt es nach der Fertigstellung? Mit Namen. Software ohne benannte Zuständigkeit ist eine Verbindlichkeit, kein Vermögenswert.
Was passiert, wenn es ausfällt? Für ein internes Hilfsmittel: nichts Schlimmes. Für etwas, das in einem Kundenprozess hängt: Planen Sie den Ausfall ein, bevor Sie ihn erleben.
Wie kommen wir wieder heraus? Steht der Quelltext bei Ihnen? Können Sie die Daten exportieren? Hängt alles an einem einzigen Dienst? Diese Frage ist bei schnell gebauter Software wichtiger als bei langsam gebauter, weil die Entscheidung dafür schneller gefallen ist.
Was eine gute Zusammenarbeit mit dem Modell ausmacht
Vier Dinge unterscheiden brauchbare Ergebnisse von Bastelei:
- Kleine Schritte. Eine Funktion, prüfen, nächste Funktion. Wer vierhundert Zeilen auf einmal erzeugen lässt, prüft sie nicht.
- Tests zuerst verlangen. „Schreibe zuerst die Prüfungen, dann die Funktion“ ist die wirksamste einzelne Anweisung in diesem Feld. Sie zwingt beide Seiten, vorher zu sagen, was richtig ist.
- Den Zusammenhang mitgeben. Welche Sprache, welche Fassung, welche Hausregeln, welche vorhandenen Bausteine. Dazu Prompts, die funktionieren.
- Nichts übernehmen, was niemand versteht. Quelltext, den im Haus niemand erklären kann, ist technische Schuld mit Zinseszins. Lassen Sie sich erklären, was dasteht – das können diese Werkzeuge gut, und es ist der unterschätzte Teil ihres Nutzens.
Der Punkt, an dem es kippt
Es gibt einen Moment in fast jedem dieser Vorhaben: Der Prototyp funktioniert, jemand zeigt ihn der Geschäftsführung, und die Frage lautet, warum man das nicht gleich einsetzt. Die Antwort auf diese Frage entscheidet über die nächsten zwei Jahre.
Was dann fehlt, ist in der Regel: Rechteverwaltung, Protokollierung, Umgang mit Fehleingaben, Sicherungen, Datenschutzdokumentation, eine zweite Person, die den Quelltext kennt. Das sind keine Feinheiten, das ist der Übergang von „läuft bei mir“ zu „läuft im Betrieb“, und er kostet typischerweise ein Mehrfaches des Prototyps.
Die brauchbare Haltung dazu ist nicht Vorsicht, sondern Klarheit: Ein Prototyp darf drei Tage dauern, wenn allen klar ist, dass er ein Prototyp ist. Problematisch wird er erst, wenn er heimlich befördert wird.
Websites und Außendarstellung
Für Websites gilt dasselbe mit einem Zusatz: Was nach außen sichtbar ist, trägt Ihren Namen. Erzeugte Texte gehören gelesen, erzeugte Bilder geprüft und gekennzeichnet, siehe Kennzeichnung und Transparenz. Und die Pflichtangaben – Impressum, Datenschutz, Barrierefreiheit, soweit einschlägig – sind kein Thema, das ein Werkzeug erledigt, auch wenn es den Text dafür entwirft.
Was das im Mentoring bedeutet
Eigenbau taucht im Programm in der Phase REALISIERUNG auf, und zwar dann, wenn der Vergleich aus der Phase UMSETZUNG ergeben hat, dass kein eingekauftes Werkzeug passt – siehe KI-Werkzeuge auswählen. Der Business-Case-Einseiter rechnet in diesem Fall nicht nur den Bau, sondern auch Betrieb und Wartung über drei Jahre; diese Zeile ist regelmäßig die, die die Entscheidung dreht – in beide Richtungen.
Häufige Fragen
Kann man ohne Programmierkenntnisse eine App bauen lassen?
Einen lauffähigen Prototyp: oft ja. Eine Anwendung, die Kundendaten verarbeitet und jahrelang läuft: nein, jedenfalls nicht verantwortbar. Der Unterschied liegt nicht im Schreiben des Quelltextes, sondern in den Entscheidungen darum herum – wo Daten liegen, wer zugreifen darf, was bei einem Fehler passiert, wer das in zwei Jahren wartet. Diese Fragen stellt kein Werkzeug von selbst.
Was ist der häufigste Fehler bei solchen Vorhaben?
Die Verwechslung von Prototyp und Produkt. Nach drei Tagen steht etwas, das funktioniert, sieht gut aus und alle begeistert – und genau deshalb wird entschieden, es produktiv zu nehmen. Was fehlt, ist alles, was man nicht sieht: Rechteverwaltung, Protokollierung, Sicherungen, Fehlerbehandlung, Wartbarkeit. Das ist nicht ein Rest, das ist der größere Teil der Arbeit.
Lohnt sich das für einen Mittelständler ohne IT-Abteilung?
Für interne Werkzeuge mit überschaubarem Risiko: deutlich. Rechner, Formulare, Auswertungen, kleine Hilfsmittel, die bisher in Tabellen und Köpfen steckten, lassen sich heute in Tagen bauen statt in Monaten. Für alles, was Kundendaten verarbeitet oder nach außen sichtbar ist, brauchen Sie jemanden, der es verantwortet – intern oder als Dienstleister.