Ein Kunde hat mir im Frühjahr eine Anwendung gezeigt, die eine Mitarbeiterin aus der Auftragsabwicklung im Training gebaut hatte. Sie lief seit vier Monaten, sparte dem Team spürbar Zeit, und alle waren zufrieden.
Dann habe ich gefragt, wer sie anpasst, wenn sich der Prozess ändert. Es entstand eine Pause, wie sie in solchen Gesprächen oft entsteht.
Die Mitarbeiterin war zu dem Zeitpunkt in Elternzeit.
Selbstgebaute Werkzeuge lösen ein reales Problem: Prozesse, für die sich nie ein IT-Projekt gelohnt hätte, werden endlich digital. Dafür entsteht ein neues Problem, und es zeigt sich erst nach Monaten.
Klassische Unternehmenssoftware hat einen Hersteller. Wenn sich das Steuerrecht ändert, kommt ein Update. Wenn etwas kaputt ist, gibt es eine Hotline. Diese Selbstverständlichkeit fällt weg, sobald das Werkzeug im eigenen Haus entstanden ist.
Das ist kein Argument gegen den Ansatz. Es ist ein Argument dafür, die Frage vorher zu stellen statt hinterher.
Ich gehe diese Liste mit Kunden durch, bevor das erste selbstgebaute Tool echte Daten sieht. Sie dauert vierzig Minuten.
Wer ändert es? Damit meine ich nicht, wer es gebaut hat, sondern wer es in einem Jahr anpasst. Es sollten mindestens zwei Personen sein, die den Aufbau verstehen. Eine reicht nicht, das zeigt spätestens die erste Elternzeit.
Wo liegen die Daten? Bei welchem Anbieter, in welchem Land, und wer hat außer Ihnen Zugriff. Bei Personaldaten sollte die Antwort auf die Länderfrage in der EU liegen.
Wer kommt rein? Gibt es einen Login, sind die Rollen sinnvoll getrennt, und wird der Zugang wirklich gesperrt, wenn jemand das Unternehmen verlässt. Der letzte Punkt fällt in der Praxis am häufigsten hinten runter.
Was passiert bei einem Ausfall? Wenn die Anwendung morgens nicht startet: Wie lange dauert es, bis das jemandem auffällt, und wie arbeitet das Team in der Zwischenzeit weiter. Für einen Urlaubsantrag ist ein Tag Ausfall verkraftbar. Für die Schichtplanung in der Produktion nicht.
Gibt es eine Sicherung, und hat schon einmal jemand versucht, sie zurückzuspielen? Eine ungetestete Sicherung ist eine Vermutung.
Was kostet der Betrieb? Die laufenden Kosten für Datenbank und Hosting liegen bei kleinen Anwendungen meist unter 50 Euro im Monat. Das ist selten das Problem. Das Problem ist, dass die Rechnung auf der privaten Kreditkarte der Mitarbeiterin landet, weil das im Training am schnellsten ging.
KI-Werkzeuge bauen brauchbaren Code, aber sie treffen Sicherheitsentscheidungen nicht von selbst. Sie schreiben, was Sie beschreiben. Wenn in der Beschreibung nicht vorkommt, dass Mitarbeiter A die Daten von Mitarbeiter B nicht sehen darf, wird diese Trennung auch nicht eingebaut.
Das ist keine Eigenart der Technologie. Ein menschlicher Entwickler, dem niemand etwas von Zugriffsrechten sagt, baut sie ebenso wenig ein.
Der Unterschied liegt woanders: Beim klassischen Projekt sitzt jemand am Tisch, der aus Erfahrung nachfragt. Bei einem selbstgebauten Werkzeug fragt niemand, weil niemand weiß, dass man fragen müsste.
Deshalb ist mein wichtigster Rat zu diesem Thema unspektakulär: Lassen Sie jemanden mit Sicherheitserfahrung eine Stunde draufschauen, bevor echte Daten hineinkommen. Eine Stunde. Das ist der gesamte Aufwand, und er ersetzt keine Zertifizierung, findet aber die Fehler, die wirklich weh tun.
Führen Sie eine Liste. Eine einzige Tabelle, in der jedes selbstgebaute Werkzeug steht: Name, Zweck, wer betreut es, wo liegen die Daten, wann wurde es zuletzt angefasst.
Das klingt nach Bürokratie und ist das Gegenteil davon. Ohne diese Liste haben Sie nach zwei Jahren neun Anwendungen im Haus, von denen drei niemand mehr zuordnen kann. Mit der Liste haben Sie eine Übersicht, die auf eine Seite passt.
Bei dem Kunden aus dem ersten Absatz haben wir übrigens einen Kollegen eingearbeitet. Es hat einen Nachmittag gedauert, weil die Anwendung klein und der Prozess klar war. Das ist der andere Teil der Wahrheit über selbstgebaute Werkzeuge: Sie sind meist so überschaubar, dass die Übergabe nicht das Drama ist, das man befürchtet.
Eine funktionierende App in anderthalb Tagen ist keine Übertreibung. Die ehrliche Frage kommt danach: Was zwischen dem Prototyp und dem Produktivbetrieb noch liegt, und warum dieser Teil meistens unterschätzt wird.
Vibe Coding und klassische Softwareentwicklung sind keine Konkurrenten. Aber zu wissen, wann man welchen Ansatz wählt, spart Zeit und Geld.
Vibe Coding klingt verlockend: Einfach beschreiben, was man braucht, und die KI baut es. Aus echten Projekten weiß ich, wo das stimmt und wo nicht.
