Individualsoftware mit KI bauen – warum sich die Rechnung geändert hat

Jahrzehntelang galt eine einfache Regel: Individualsoftware ist etwas für Konzerne. Der Mittelstand kauft Standardsoftware und passt seine Prozesse an – nicht umgekehrt. Diese Regel gilt nicht mehr, und der Grund ist KI-gestützte Entwicklung.

Ich schreibe das nicht als Beobachter, sondern aus eigener Praxis: In den letzten Jahren habe ich mehrere interne Werkzeuge selbst gebaut – vom eigenen Akquise-CRM bis zum internen Tool-Index, der unsere Deployments und Standards dokumentiert. Nichts davon hätte sich vor fünf Jahren gerechnet. Heute entsteht so etwas in Tagen bis Wochen, neben dem Tagesgeschäft.

Was sich geändert hat

Werkzeuge wie Claude Code oder Codex schreiben nicht nur Codezeilen schneller. Sie verändern die Struktur der Arbeit: Ein kleines Team – oder eine einzelne Person mit Prozessverständnis – kann heute in Wochen bauen, wofür früher ein Projektteam Monate brauchte. Der Engpass verschiebt sich vom Programmieren zum Präzisieren: Wer genau beschreiben kann, wie ein Prozess funktionieren soll, bekommt funktionierende Software.

Das klingt banal, ist aber eine Umkehrung der bisherigen Ökonomie. Früher war die Implementierung der teure Teil – Lastenheft, Angebot, Entwicklungsteam, Abnahme. Die Kosten waren so hoch, dass nur Prozesse mit sehr großem Volumen sie rechtfertigten. Wenn die Implementierung aber billig wird, dreht sich die Rechnung: Plötzlich ist das knappe Gut nicht mehr Entwicklungszeit, sondern das Wissen darüber, wie der Prozess wirklich funktioniert. Und dieses Wissen sitzt im Unternehmen selbst, nicht beim Dienstleister.

Genau deshalb profitiert der Mittelstand überproportional. Konzerne konnten sich Individualsoftware schon immer leisten. Neu ist, dass sich ein Zwanzig-Personen-Betrieb ein maßgeschneidertes Werkzeug für seine Angebotserstellung bauen lassen kann – oder es mit etwas Anleitung selbst baut.

Ein Beispiel aus der eigenen Praxis

Unser Akquise-CRM ist dafür ein gutes Anschauungsobjekt. Die Anforderung war speziell: E-Mails aus zwei Firmen-Postfächern automatisch mitlesen, daraus Kontakte und Firmen aufbauen, Follow-ups verwalten – ohne dass jemand Daten pflegen muss, und ohne dass ein Cloud-Anbieter unsere gesamte Geschäftskommunikation erhält. Kein Standard-CRM bildet das so ab; HubSpot und Pipedrive wollen, dass man ihren Prozess übernimmt.

Die klassische Antwort wäre gewesen: damit leben. Die neue Antwort war: das Werkzeug in wenigen Wochen selbst bauen, exakt entlang des eigenen Arbeitsablaufs. Der entscheidende Aufwand steckte nicht im Code, sondern in den Entscheidungen davor – welche Mails zählen als Akquise, wann gilt ein Kontakt als kalt, was passiert bei Antworten. Das ist Prozessarbeit, keine Programmierarbeit. Der Code war danach das kleinste Problem.

Wo Individualsoftware jetzt sinnvoll ist

Aus unserer Projektpraxis haben sich drei Muster herausgebildet:

• Der Lücken-Fall: Zwischen zwei Standardsystemen klafft ein Loch, das mit Excel und E-Mail überbrückt wird. Jemand exportiert aus System A, formatiert um, importiert in System B – jede Woche, seit Jahren. Genau diese Brücken sind heute günstig zu bauen, und sie amortisieren sich oft innerhalb weniger Monate.
• Der Alleinstellungs-Fall: Ein Prozess ist das, was ein Unternehmen besonders macht – die Art, wie es kalkuliert, konfiguriert, berät. Ihn in Standardsoftware zu pressen, hieße, den Vorteil wegzuwerfen. Hier war Individualsoftware schon immer richtig; neu ist nur, dass sie bezahlbar ist.
• Der Automatisierungs-Fall: Wiederkehrende Aufgaben mit klaren Regeln – Angebotserstellung, Datenaufbereitung, Reporting – lassen sich mit KI-Agenten direkt in den Arbeitsfluss integrieren. Das ist die jüngste Kategorie und die mit dem größten Hebel, weil hier nicht nur Software entsteht, sondern Arbeit tatsächlich wegfällt.

Wo sie es nicht ist

Zur Ehrlichkeit gehört auch die Gegenliste. Buchhaltung, Lohnabrechnung, Standardvertrieb – alles, was gesetzlich normiert oder branchenweit identisch ist, gehört in Standardsoftware. Dort stecken Jahrzehnte an Sonderfällen, Zertifizierungen und Pflege, die niemand nachbauen sollte, nur weil er es jetzt könnte. Die Frage ist nie „Können wir das selbst bauen?" – das können heute viele. Die Frage ist, ob der Prozess unternehmensspezifisch genug ist, dass sich eigene Software lohnt, und ob jemand bereit ist, sie dauerhaft zu verantworten.

Wie ein Projekt heute abläuft

Was sich in unseren Projekten bewährt hat, ist ein kurzer, iterativer Ablauf statt des klassischen Lastenhefts: Zuerst wird der echte Prozess aufgenommen – nicht der dokumentierte, sondern der gelebte, mit allen Excel-Zwischenschritten. Daraus entsteht innerhalb weniger Tage ein funktionierender Prototyp, an dem die späteren Nutzer früh arbeiten. Dann wird iteriert: Was stört, fliegt raus; was fehlt, kommt dazu. Nach wenigen Wochen läuft das Werkzeug produktiv, und ab dann wächst es mit dem Prozess mit.

Der Unterschied zum alten Modell: Es gibt keinen Punkt, an dem eine dicke Spezifikation „eingefroren" wird. Die Software bleibt so beweglich wie der Prozess, den sie abbildet. Wie man diesen Einstieg richtig aufsetzt, habe ich in einem eigenen Beitrag beschrieben: KI-Beratung richtig starten.

Was gleich geblieben ist

KI schreibt Code, aber sie verantwortet ihn nicht. Drei Dinge bleiben Handarbeit: das Verständnis für den tatsächlichen (nicht den dokumentierten) Prozess, die Entscheidung, was die Software bewusst nicht können soll, und der Betrieb – Updates, Sicherheit, Weiterentwicklung. Software, die niemand pflegt, ist eine Hypothek mit Benutzeroberfläche.

Gerade der letzte Punkt wird unterschätzt. Die niedrige Einstiegshürde verführt dazu, viele kleine Werkzeuge zu bauen und sie dann verwildern zu lassen. Wir haben darauf mit einem internen Standard reagiert: Jedes Tool wird gleich deployt, gleich dokumentiert und taucht in einem zentralen Index auf. Wer Individualsoftware ernst meint, braucht so eine Disziplin – sonst tauscht man das Excel-Chaos nur gegen ein Tool-Chaos.

Fazit

Die Frage ist nicht mehr „Können wir uns Individualsoftware leisten?", sondern „Welcher unserer Prozesse verdient sie zuerst?". Wer die Antwort sucht, sollte nicht bei der Technik anfangen, sondern beim Prozess, der heute am meisten Reibung erzeugt – dort, wo Excel-Listen kursieren, Daten doppelt gepflegt werden und jeder weiß, dass es „eigentlich anders laufen müsste". Genau da lohnt sich der erste Prototyp. Und wer sehen will, wie das konkret aussieht: Mein eigenes CRM ist so entstanden.