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

tl;dr
ai-gestuetztes development macht eigenentwicklung fuer den mittelstand erstmals wirtschaftlich: schnellere entwicklung, dramatisch guenstigere wartung, software die sich an prozesse anpasst statt umgekehrt. saas verliert seinen oekonomischen burggraben. die neue kernkompetenz heisst nicht programmieren, sondern software design — verstehen was gebraucht wird und es schnell realisieren.

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

»wer soll das alles warten?«

dieser satz war in den letzten 30 jahren meist das 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, infrastruktur.

die laufenden kosten wurden systematisch unterschaetzt. nicht um zehn oder zwanzig prozent, sondern um ein vielfaches.

man kann das am besten an den digitalisierungsprojekten der bundesrepublik beobachten [1, 2]. die logik war immer dieselbe: wir bauen projekt a, dann b, dann c. diese logik hat nie funktioniert.

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: nicht fehlender wille, sondern eine grundlegend falsche kostenrechnung.

die alte gleichung: saas war immer billiger als selbst bauen

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.

unternehmen haben ueber jahre ihre ablaeufe um die limitierungen ihrer saas-tools herum gebaut. 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 jemandem aus der marketingabteilung dabei zugesehen hat, wie google ads gepflegt werden, weiss wovon ich spreche.

die disruption: eine person kann heute das, was frueher ein team brauchte

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

ai-gestuetztes software development hat 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.

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 nutzern.«

der hebel ist dabei nicht nur geschwindigkeit. der eigentliche durchbruch ist, was mit dem entwicklungsprozess selbst passiert: 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. stattdessen: ein tool das genau das tut, was die dreissig leute in der abteilung brauchen. und das morgen schon steht.

die wartungsfrage, neu gestellt: ai uebernimmt die routinearbeit

und die wartung?

»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 sinken so dramatisch, dass die alte rechnung »laufende kosten machen eigenentwicklung unwirtschaftlich« nicht mehr aufgeht.

was das fuer saas bedeutet: die zahlen sprechen eine klare sprache

die saas-industrie spuert es bereits.

−29%netto-neuer arr, q1 2024 → q1 2025

−6,5%saas-index 2025, waehrend s&p +17,6%

<5×bewertungsmultiples, von ueber 7× gefallen

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 [3, 4]. die bewertungsmultiples sind von ueber sieben auf unter fuenf gefallen [5].

»in der agent-aera werden business-applikationen kollabieren. die gesamte geschaeftslogik wandert in die ai-schicht.«

— satya nadella, bg2-podcast, dezember 2024 [6]

saas wird nicht verschwinden. aber die marktmacht verschiebt sich. der lock-in bricht, weil die alternative — »selbst bauen ist noch teurer« — gerade wegfaellt.

der neue job: software designer statt ticket-abarbeiter

alle reden davon, dass software development vorbei ist. das stimmt 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.

der software designer fragt: wie sollte das hier eigentlich funktionieren? er denkt in systemen, versteht prozesse, stellt die richtigen fragen — und legt die antwort in wenigen tagen als funktionierenden prototyp in die haende der nutzer.

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.

von starrer zu fluessiger software

die transformation laesst sich in einem bild zusammenfassen: von starrer software, die prozesse diktiert, zu fluessiger 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.

ai wird nie wieder schlechter sein als an diesem punkt. 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 konsequenzen, wenn das stimmt

1. change management wird zur ueberlebensfrage

change management ist hart und scheitert haeufiger als es gelingt. jede softwareentwicklungsabteilung steht vor einer transformation, die in ihrem ausmass 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 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

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

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

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.

quellen [1] A. Prange, »digitalisation in germany: an overview and what lies behind the delays,« osw centre for eastern studies, nov. 2021. osw.waw.pl [2] S. Kuhlmann et al., »digitizing bureaucracy: insights from the digital transformation of germany's local government sector,« in public administration in germany, springer, 2025. springer.com [3] J. Lemkin, »saas is still slowing down: what q1 2025 numbers reveal,« saastr, 2025. saastr.com [4] J. Ball, »net new arr trends,« clouded judgement, mai 2025. cloudedjudgement.substack.com [5] Bessemer Venture Partners, »the bvp nasdaq emerging cloud index,« 2025. cloudindex.bvp.com [6] S. Nadella, »interview im bg2 podcast mit bill gurley & brad gerstner,« dez. 2024. youtube.com [7] P. A. David, »the dynamo and the computer: an historical perspective on the modern productivity paradox,« american economic review, vol. 80, no. 2, 1990. jstor.org