fluessige software: warum jetzt der zeitpunkt fuer mittelstaendische unternehmen in eigene software zu investieren

die oekonomie von build-vs-buy hat sich unwiederbringlich verschoben. nicht irgendwann. jetzt.

"wer soll das alles warten?"

dieser satz, den jeder in einem unternehmen mit verantwortungsvollem cto schon einmal gehoert hat, war in den letzten 30 jahren meist das mittelbare ende jeder diskussion ueber eigenentwicklung. und er war berechtigt! die rechnung war klar: eigene software fuer interne aufgaben, marketing-tools, hr-workflows, branchenspezifische prozesse; das lohnt sich fast nie. man braucht mindestens zwei entwickler, bevor irgendetwas produktiv laeuft vergehen monate, und dann faengt die eigentliche arbeit erst an: updates, sicherheitspatches, anpassungen an neue anforderungen, infrastruktur. die laufenden kosten einer digitalen loesung wurden systematisch unterschaetzt. nicht um zehn oder zwanzig prozent, sondern um ein vielfaches.

man kann das am besten an den digitalisierungsprojekten der bundesrepublik und ihrer kommunen beobachten [1, 2]. die logik war immer dieselbe: wir bauen projekt a, dann geht es weiter zu b, dann c. diese logik hat nie funktioniert. denn ein papierformulargestuetzter prozess kann einmal von qualifizierten mitarbeitern durchdacht und dann mit minimalem wartungsaufwand jahrelang weitergefuehrt werden. ein digitalprojekt erfordert permanente weiterarbeit von spezialisten. das war der eigentliche grund, warum digitalisierung in deutschland so oft gescheitert ist: nicht fehlender wille, sondern eine grundlegend falsche kostenrechnung.

die alte gleichung

genau diese kostenrechnung hat saas zum dominanten modell gemacht. und saas-anbieter haben sie schamlos ausgenutzt.

das pricing war immer exakt so kalibriert, dass sich eigenentwicklung nicht lohnte. fuenf euro pro nutzer pro monat klingt nach wenig, bis du realisierst, dass du fuer 200 mitarbeiter 12.000 euro im jahr zahlst fuer ein tool, das achtzig prozent von dem kann, was du brauchst. die fehlenden zwanzig prozent? dafuer passt du deine arbeitsprozesse an die software an, nicht umgekehrt.

das ist ein trade-off, der systematisch unterschaetzt wird. unternehmen haben ueber jahre ihre ablaeufe um die limitierungen ihrer saas-tools herum gebaut. nicht weil die tools schlecht waren, sondern weil die alternative, eigenentwicklung, immer teurer war als die anpassung der eigenen prozesse. der lock-in entstand nicht durch technische barrieren allein, sondern durch oekonomische: solange "selbst bauen" unbezahlbar war, gab es keine exit-option.

hinzu kommen die dark patterns der saas-branche: nicht usability steht im vordergrund, sondern lock-in. die ui wirkt auf den ersten blick einfach, aber unter der oberflaeche stecken dutzende kleine quirks, fuer die mitarbeiter geschult oder schlimmer, die haendisch gewartet werden muessen. jeder, der einmal die gelegenheit hatte jemandem aus der marketing abteilung dabei zugesehen, wie google ads gepflegt werden, weisz wovon ich spreche.

fundamentale disruption

diese spielregeln haben sich veraendert. nicht graduell, sondern fundamental.

ai-gestuetztes software development hat spaetestens mit dem release von claude opus 4.5 einen punkt erreicht, an dem die build-vs-buy-gleichung kippt. eine einzelne person kann heute ein internes tool, dessen entwicklung frueher drei monate mit einem kleinen team erfordert haette, in ein bis zwei wochen realisieren. das ist keine marketingaussage: das ist meine taegliche erfahrung.

der hebel ist dabei nicht nur geschwindigkeit. der eigentliche durchbruch ist, was mit dem entwicklungsprozess selbst passiert: aus "lange planen, lange entwickeln, dann feststellen dass der stakeholder eigentlich etwas anderes gebraucht haette" wird "ich baue den prototyp in wenigen tagen und iteriere direkt mit den zukuenftigen nutzern." die feedbackschleife, die frueher monate gedauert hat, schrumpft auf tage.

das gilt insbesondere fuer interne tools: anwendungen im intranet, die nicht den harschen requirements des offenen internets genuegen muessen. keine compliance mit jedem browser seit 2015. keine skalierung auf millionen nutzer. keine saas-level security audits. stattdessen: ein tool das genau das tut, was die dreiszig leute in der abteilung brauchen. und das morgen schon steht.

die wartungsfrage, neu gestellt

und die wartung? hier kommt der zweite teil der verschiebung.

"wer soll das alles warten?" war die richtige frage in einer welt, in der jede codeaenderung menschliche arbeitszeit bedeutete. in einer welt, in der ai routinemaessige updates, sicherheitspatches und anpassungen uebernehmen kann, veraendert sich die antwort fundamental. der mensch steuert konzeptionell: was soll die software tun? wie sollen sich die prozesse entwickeln? die maschine uebernimmt die umsetzung.

ich sage bewusst nicht, dass wartung "vollstaendig automatisiert" wird. wer das behauptet, hat noch nie ein legacy-system gesehen. aber die kosten fuer wartung sinken so dramatisch, dass die alte rechnung "laufende kosten machen eigenentwicklung unwirtschaftlich" nicht mehr aufgehen kann. und das veraendert alles.

was das fuer saas bedeutet

die saas-industrie spuert es bereits. die quartalszahlen sprechen eine klare sprache: der aggregierte netto-neue arr ueber alle cloud-software-unternehmen fiel von 2,33 milliarden dollar im ersten quartal 2024 auf 1,65 milliarden im ersten quartal 2025, ein rueckgang von 29 prozent [3, 4]. waehrend der s&p 500 in 2025 um 17,6 prozent stieg, fiel der saas-index um 6,5 prozent. die bewertungsmultiples sind von ueber sieben auf unter fuenf gefallen [5].

satya nadella hat es im dezember 2024 im bg2-podcast unverbluemt formuliert: in der agent-aera werden business-applikationen kollabieren, die gesamte geschaeftslogik wandert in die ai-schicht [6].

das ist keine dystopie fuer saas-unternehmen. es ist ein paradigmenwechsel. saas wird nicht verschwinden; aber die marktmacht verschiebt sich. der lock-in bricht, weil die alternative, die ihn stabilisiert hat, das argument "selbst bauen ist noch teurer", gerade wegfaellt.

der neue job: software designer

alle reden davon, dass software development vorbei ist. das stimmt aber nur teilweise. was verschwindet, ist der job, bei dem jemand tickets abarbeitet ohne den kontext zu verstehen. das war schon immer nicht besonders sinnvoll. jetzt ist es ueberfluessig.

was entsteht, ist etwas anderes: der software designer. der systemanalyst. der mensch, der kreativ und disruptiv fragt: wie sollte das hier eigentlich funktionieren? der in systemen denkt, prozesse versteht, die richtigen fragen stellt und dann die antwort in wenigen tagen als funktionierenden prototyp in die haende der nutzer legt. gemeinsam wird rapid optimiert.

das ist eine fundamental andere kompetenz als programmieren. es ist die faehigkeit, ein problem zu sehen, es zu durchdringen und eine loesung zu entwerfen, die den arbeitsprozess optimiert statt ihn in ein bestehendes tool zu pressen. diese kompetenz wird zum neuen spielfeld, auf dem unternehmen sich echte wettbewerbsvorteile erarbeiten.

fluessige software

die transformation laesst sich in einem bild zusammenfassen: von starrer software, die prozesse diktiert, zu liquider software, die sich an prozesse anpasst.

frueher: ein langwieriger, strukturierter entwicklungsprozess, der vermieden werden sollte wo immer moeglich, weil die kosten immer ein vielfaches hoeher waren als geplant.

jetzt: software, die das tut, was das unternehmen tatsaechlich braucht. die sich agil anpassen laesst. die den optimalen arbeitsprozess abbildet, statt den arbeitsprozess an ein saas-tool anzupassen.

und eines muss man sich bewusst machen: ai wird nie wieder schlechter sein als an diesem punkt. es wird nur besser. die tools die heute einen zehnfachen produktivitaetsgewinn ermoeglichen, sind die schlechteste version dessen, was kommt.

wer jetzt nicht umschaltet, wird nicht langsam abgehaengt. er wird ploetzlich feststellen, dass der wettbewerber, der seine interne software selbst baut, schneller iteriert, besser an seine kunden angepasst ist und weniger fuer tools bezahlt, die nur achtzig prozent von dem koennen, was er braucht.

die frage ist nicht mehr "lohnt sich eigenentwicklung?" die frage ist: "koennen wir es uns leisten, es nicht zu tun?"

fuenf punkte die daraus folgen, wenn ich recht habe

1. change management wird zur ueberlebensfrage.
change management ist hart und scheitert haeufiger als dass es gelingt. jede softwareentwicklungsabteilung steht nun vor einer transformation, die in ihrem ausmasz wenige historische parallelen kennt; und die wenigen die es gibt, sind ernuechternd. als in den 1890ern elektromotoren die dampfmaschine abloesten, haben die meisten fabrikbesitzer einfach den antrieb ausgetauscht: gleiche fabrik, gleiches layout, kaum produktivitaetsgewinn. der wirtschaftshistoriker paul david hat das in einer einflussreichen studie gezeigt [7]: erst die unternehmen, die ihre gesamte produktion um verteilte elektrizitaet herum neu dachten, haben den echten sprung gemacht. das hat eine generation gedauert. die parallele ist fast unheimlich: wer ai einfach in den bestehenden entwicklungsprozess steckt, gleiche jira-boards, gleiche sprints, nur schneller, wird kaum profitieren. wer den prozess selbst neu denkt, gewinnt alles.

2. die alten werkzeuge koennen weg.
alle tools, prozesse und arbeitsablaeufe, die bisher softwareentwicklung gesteuert haben, koennen in die tonne. jira-boards, sprint-plannings, story-point-schaetzungen: artefakte einer aera, in der entwicklungszeit die knappste ressource war. das problem: es ist noch nicht klar, wie man die neue arbeitsorganisation gut steuert. sie wird neue probleme haben, die neue strukturen erfordern. wer an den alten strukturen festhaelt, verliert.

3. gute entwickler sind nicht automatisch gute software designer.
der software designer kann gut kommunizieren, kann sich in arbeitsprozesse anderer hineindenken, kann strukturieren und kreativ loesungen erarbeiten. das sind soft skills, die in der klassischen entwicklerausbildung kaum vorkommen. manche entwickler werden diesen sprung machen, andere nicht und das ist weniger eine frage der intelligenz, sondern eher von persoenlichkeit.

4. unternehmen ohne eigene entwicklung sollten jetzt anfangen.
unternehmen, die bisher keine eigene software entwickelt haben, sollten die gelegenheit nutzen: ein kleines software-design-team aufbauen. nicht zehn entwickler einstellen, sondern zwei bis drei leute, die in systemen denken und mit ai-tools umgehen koennen. das ist der kompetitive vorteil von morgen.

5. es ist ok, traurig zu sein.
fuer alle entwickler und die menschen, die entwickler durch die naechsten jahre begleiten, gilt: wer bisher stolz daraus gezogen hat, detailaufgaben gruendlich zu durchdenken und eleganten code zu schreiben, der verliert etwas, das ihm emotional etwas bedeutet hat. das macht traurig und das ist ok. aber es aendert die realitaet nicht.