Stehen wir vor einer Renaissance der Individualsoftware im Mittelstand?

Über KI und Software wird 2026 viel diskutiert. An den Börsen sind die Werte klassischer Software-Anbieter deutlich gefallen, aus Sorge, dass KI-Agenten das Modell der Lizenz pro Nutzer ablösen.¹ Andere halten dagegen, KI werde die Branche eher vergrößern als zerstören, weil der Wert nie allein im Code lag.² Diese Diskussion dreht sich um die großen Software-Häuser und ihre Bewertungen. Mich beschäftigt eine andere Frage, weil ich aus dieser Ecke komme: was der Sturz der Entwicklungskosten für den wenig digitalisierten Mittelstand bedeutet, für die Unternehmen, die von Standardsoftware ohnehin nie gut bedient wurden.

Zwischen der großen Standardsoftware wie SAP oder Salesforce und der Excel-Telefon-PDF-Wirklichkeit im Alltag liegt eine Lücke: genau das Werkzeug, das ein Unternehmen für ein spezifisches Problem bräuchte, und solche Probleme gibt es oft an mehreren Stellen. Diese Mitte war bisher wirtschaftlich fast nie erreichbar, weil individuell zu bauen zu aufwändig, zu langsam und zu riskant war.

Ich glaube, das ändert sich gerade, weil die Kosten, funktionale Software zu bauen, in kurzer Zeit dramatisch gefallen sind. Mich erinnert das an die Long-Tail-Theorie von vor ca. 20 Jahren. Ursprünglich beschreibt sie, warum sinkende Produktions- und Vertriebskosten Hunderte, Tausende oder Millionen einzelner, wenig nachgefragter Nischenprodukte wirtschaftlich machten. Denselben Effekt sehe ich jetzt in der Softwareentwicklung: nicht sinkende Vertriebskosten, sondern sinkende Entwicklungskosten verschieben die Wirtschaftlichkeitsschwelle, bis hin zur Software in Stückzahl 1.

Meine Vermutung: Der Hebel ist dort am größten, wo die Not am größten ist, also ausgerechnet in den Branchen, die bisher am wenigsten digitalisiert sind. Einlösen wird ihn aber zuerst, wer im eigenen Unternehmen anfängt, die Daten in Ordnung zu bringen. Und sollte sich diese Entwicklung fortsetzen, stünde tatsächlich eine Renaissance der Individualsoftware bevor.

Das Problem der fehlenden Mitte

Ich habe die letzten Jahre in der Baubranche verbracht und sie ist ein ideales Beispiel, um das Thema anschaulich zu machen: Beim Digitalisierungsindex des IW Köln steht sie ganz hinten und das ist auch meine subjektive Erfahrung. Die Branchengruppe Baugewerbe, Ver- und Entsorgung liegt mit 67,6 Punkten auf dem letzten Platz aller Branchengruppen, weit unter dem Gesamtschnitt von rund 114 und der Spitzengruppe IKT mit 285.³ In der EU arbeiten rund vier Millionen Bauunternehmen, der Großteil davon Kleinbetriebe mit unter 20 Beschäftigten.⁴ Die Wertschöpfungsketten sind fragmentiert, die Prozesse weitgehend papierbasiert, und genau das macht es so schwer, Standardlösungen durchzusetzen.

Bisher gab es im Wesentlichen drei Optionen.

Große Standardsoftware. SAP, Salesforce, branchenspezifische ERP-Systeme. Mächtig, aber gebaut für Unternehmen mit eigener IT-Abteilung, großen Lizenz- und Einführungsbudgets und der Bereitschaft, die eigenen Prozesse an die Software anzupassen. Für einen Abdichtungshersteller mit 120 Mitarbeitern und einer Produktdatenbank in Excel ist das keine realistische Option.

Branchenspezifische Fachsoftware. Speziell in meinem Fokusfeld, der Dachbaubranche, sind das Anbieter wie Win-Dach oder MFDach: Es gibt durchaus spezialisierte Werkzeuge für Aufmaß, Dachplanung und Kalkulation, und sie werden breit eingesetzt. Aber sie sind auf das Handwerksproblem zugeschnitten, nicht auf das Unternehmensproblem. Sie standardisieren innerhalb ihrer Nische: Jeder Dachdecker arbeitet mit derselben Oberfläche, derselben Logik, denselben Grenzen. Was sie nicht abbilden, sind die spezifischen Produktlogiken eines einzelnen Herstellers, seine Vertriebsstrukturen, seine Datenflüsse zum Händler. Dafür sind sie nicht gemacht, und für die Anbieter wäre es vermutlich auch kein tragfähiges Geschäft, das pro Hersteller individuell zu bauen.

Excel, Telefon, PDF. Die De-facto-Lösung für alles, was zwischen den ersten beiden Optionen liegt. Der Großteil der Produktdaten in der Baustoffbranche wird per Excel ausgetauscht: In einer Umfrage unter Baustoff-Fachhändlern war Excel mit über 90 % das mit Abstand häufigste Austauschformat.⁵ Fachhändler rufen regelmäßig bei Herstellern an, um fehlende Stammdaten abzugleichen; jeder, der im Innendienst eines Baustoffherstellers gearbeitet hat, kennt diese Telefonate. Die Konfiguratoren der großen Hersteller enden bei PDFs und Ausschreibungstexten. Das funktioniert, solange es funktioniert.

Was aus meiner Sicht fehlt, ist die Mitte: “genau das Werkzeug, das ich brauche, für genau mein Problem” war in den letzten Jahren ökonomisch in den seltensten Fällen darstellbar. Individualsoftware bedeutete: Anforderungen sammeln, ein ganzes Projektteam beauftragen; die Dauer wurde eher in Monaten beziffert, im Extremfall in Jahren. Anschließend kostet das Ergebnis weiter Wartung, Betrieb und Weiterentwicklung. Das Risiko war damit fast immer zu groß, dass die Gesamtkosten den Nutzen übersteigen.

Was das im Bau verschärft, ist eine Eigenschaft, die den Effekt verstärkt: hohe Heterogenität, die vor allem beim einzelnen Hersteller sitzt, bei gleichzeitig hoher Prozesskomplexität. Die Hersteller haben jeweils eigene Produktlogiken, Preisstaffeln und Systemfreigaben, Bauder rechnet anders als BMI, BMI anders als Soprema, und ihre Daten müssen über einen dreistufigen Weg fließen, von Hersteller über Handel zum Handwerk. Für diesen überbetrieblichen Austausch gibt es durchaus Standards, GAEB, ETIM, BIM und andere, aber jeder deckt nur einen Teil der Wertschöpfung. GAEB ist in der Ausschreibungs- und Vergabephase etabliert, beim Handwerker auf der Baustelle dagegen kaum präsent; ein Hersteller, den ich kenne, hat GAEB aus seinen Handwerker-Anfragen wieder gestrichen, weil es dort niemand nutzt. Und keiner dieser Standards trägt die herstellereigene System-, Preis- und Rabattlogik. Das ist oft ein Unterscheidungsmerkmal, und wäre es standardisiert, wäre es keins mehr. Was ebenfalls kaum ein Standard erreicht, ist die eigene, über Jahre gewachsene Systemlandschaft in den Unternehmen, egal ob Industrie, Handel oder verarbeitende Unternehmen.

Die Schwelle verschiebt sich

Nach meiner Erfahrung sind die Kosten für die Entwicklung funktionaler Software in den vergangenen rund zwölf Monaten in einer Größenordnung gefallen, die ich vorher nicht für möglich gehalten hätte. Bei einer Handvoll Beispielen, die ich – unabhängig von den nimmermüden KI-Marktschreiern – selbst erlebt oder sogar umgesetzt habe, war die Ersparnis nicht ein Fünftel oder ein Drittel, sondern ein Vielfaches. Eine einzelne Person mit den richtigen Werkzeugen kann dort Aufgaben übernehmen, für die früher ein Projektteam nötig war.

Aber der Gewinn ist nicht automatisch, und er hängt aus meiner Sicht weniger am Werkzeug als am Vorgehen. Wer die neuen KI-Programmierwerkzeuge in den alten Ablauf einbaut, in dem am Ende doch wieder ein Mensch den meisten erzeugten Code durchsehen muss, wird nicht schneller, eher langsamer. Der Sprung kommt erst, wenn sich das Vorgehen ändert: wenn man den Agenten einen engen Rahmen aus Vorgaben und Prüfungen setzt und dem Ergebnis darin vertraut, statt alles selbst nachzulesen. KI verschiebt die Arbeit, weg vom Schreiben und Prüfen von Code, hin zum Setzen dieses Rahmens.

So hat bei einem Hersteller beispielsweise eine einzelne Person in wenigen Wochen eine grafische Bedienoberfläche gebaut, über die Aufträge zwischen einem Roboter-Palettenlager und der eigenen Lagerlogistik zugeteilt, freigegeben und überwacht werden. Sie setzt auf den vorhandenen Schnittstellen beider Systeme auf und greift nicht in deren Steuerung ein. Mit den jeweiligen Softwareherstellern der beiden Systeme wäre das ein größeres Integrationsprojekt gewesen, bei dem vermutlich allein die Projektabstimmung mehr Zeit und erst recht Geld gekostet hätte. In einem anderen Fall entstand ein komplettes Markenpaket samt Website und navigierbarem Prototyp in Stunden statt in den Arbeitstagen, die eine Agentur dafür veranschlagt hätte.

Diese Verschiebung verändert nicht, was technisch möglich ist, sondern was sich lohnt.

Die Analogie zum Long Tail ist nicht vollständig. Dort entsteht der wirtschaftliche Effekt, weil viele unterschiedliche Nischenprodukte zusammen einen großen Markt bilden. Bei Individualsoftware hat dagegen jedes Werkzeug genau einen Nutzer. Der gemeinsame Mechanismus ist jedoch derselbe: Sinkende Kosten verschieben die Wirtschaftlichkeitsschwelle. Beim Long Tail waren es Produktions- und Vertriebskosten, heute sind es Entwicklungskosten.

Warum kommen solche Lösungen nicht als Standardprodukte auf den Markt? Aus meiner Sicht ist der Markt zu fragmentiert, die Anforderungen sind zu spezifisch, die Zahlungsbereitschaft pro Einzelkunde zu gering für ein tragfähiges Standardprodukt. Als individuell gebautes Werkzeug, das eine Person als Dienstleistung oder im Unternehmen in wenigen Wochen baut statt eines Projektteams über Monate, sieht die Rechnung dagegen anders aus.

Was damit in Reichweite rückt

Unter diesen Voraussetzungen rücken für mich vor allem drei Arten von Individuallösungen in Reichweite, die vorher jenseits der Wirtschaftlichkeitsschwelle lagen. Sie setzen an genau den drei Ebenen an, an denen die vorhandenen Standards die herstellereigene Schicht nicht erreichen, und es lohnt sich, sie auseinanderzuhalten, weil sie an ganz unterschiedlichen Stellen ansetzen und jede ihre eigene Antwort verlangt.

Die erste ist das interne Werkzeug, das beispielsweise eine eigene Produkt- oder Prozesslogik abbildet: vielleicht ein Kalkulationsprogramm, das auf die Systemlogik eines Herstellers passt, nicht so generisch wie Excel und nicht so überdimensioniert wie SAP, oder ein Konfigurator, der nicht beim PDF endet, sondern eine bestellfertige Stückliste ausgibt. Weil diese Logik das Unterscheidungsmerkmal des Herstellers ist, gibt es dafür keinen Branchenstandard, an dem man sich orientieren könnte, und das interne Werkzeug ist hier nicht der Notbehelf, sondern strukturell die einzige Möglichkeit.

Die zweite ist die Integration innerhalb der eigenen, über Jahre gewachsenen Systemlandschaft, also zwischen Systemen, die im selben Unternehmen stehen und trotzdem nicht miteinander reden, so wie bei der grafischen Bedienoberfläche zwischen dem Roboter-Palettenlager und der eigenen Lagerlogistik von vorhin.

Die dritte ist die Schnittstellenbrücke nach draußen, und hier verläuft die Trennlinie am schärfsten. Beim reinen Datenaustausch, Artikelstamm, Merkmale, Listenpreis, haben die Standards eine gute und steigende Durchdringung: ETIM und BMEcat, im Dachbereich der Dach-Daten-Pool. Wer dort noch selbst baut, macht meist etwas falsch. Sobald die Brücke aber beispielsweise die interne Prozess- oder Produktlogik aus der ersten Ebene nach draußen trägt, kann kein Standard einspringen: Ein Hersteller stellt möglicherweise seine freigegebenen, garantiefähigen Aufbau-Kombinationen für das Planungstool des Architekten und den Konfigurator seines Großhändlers bereit, damit dort nur bestellbar oder planbar ist, was er auch freigibt. Das ist dieselbe herstellereigene Logik wie beim internen Werkzeug, nur nach außen gerichtet.

Was diese drei verbindet, ist weniger die konkrete Liefergröße als die Tatsache, dass eine so hochindividuelle Lösung plötzlich in Reichweite rückt, weil sie bezahlbarer und mit einem viel geringeren Risiko und früher wirtschaftlich wird.

Die ehrlichen Haken

Für einen vollständigen Blick, um nicht in den Hype zu kippen, möchte ich aus meiner Sicht auch die aktuellen Grenzen benennen.

Das Vertrauensproblem. Jeder Mittelständler kennt die Geschichte: Ein externer Entwickler baut eine individuelle Lösung, geht zum nächsten Kunden weiter, keiner kann das System warten, nach drei Jahren reißt man es wieder raus. “Wir bauen Ihnen schnell was Individuelles” löst bei erfahrenen Geschäftsführern eher Alarm aus als Begeisterung.

Aber das Risiko sinkt unter einer neuen Annahme bzw. Perspektive: Individualsoftware, die zu diesen niedrigen Kosten gebaut ist, darf auch einen kürzeren Lebenszyklus von beispielsweise 12 bis 24 Monaten haben. Sie wird nicht so umfangreich gewartet und weiterentwickelt wie ein Standardprodukt. Sie wird genutzt, sehr schnell amortisiert, und dann neu gebaut oder abgelöst. Was sich für mich damit verändert: Weil der Neubau inzwischen nur noch einen Bruchteil des früheren Aufwands verursacht, ist ein früheres Ende kein Scheitern mehr, sondern Teil des Modells. Die Individualsoftware-Leiche im Keller wird dann zum Risiko, wenn ein System gepflegt wird, das mit weniger Aufwand neu zu bauen wäre. Das war früher nie eine Option. Jetzt schon.

Das Betriebsproblem ist real. KI senkt die Entwicklungskosten, aber die laufenden Kosten bleiben: Betrieb, Datenpflege, Anpassungen, Sicherheit. Selbst ein kleines Randwerkzeug muss laufen, solange es genutzt wird. Software, bei der das egal wäre, ist von vornherein überflüssig. Hier liegt die eigentliche Falle. Ein Unternehmen hat schnell nicht eine, sondern etliche kleine Lösungen, und jede will betrieben werden. Betreibt es sie selbst, wächst die Betriebslast mit jeder Lösung, und die wenigen Personen, die den Betrieb beherrschen, werden zum Engpass; lässt es sie extern bauen, sollte das jemand tun, der den Betrieb abnimmt und dann naturgemäß sehr viele dieser Lösungen betreibt. Letztlich trägt das Modell nur, wenn der Betrieb genauso automatisiert wird wie das Bauen selbst. Diese modernen, autonomen Monitoring-, Wartungs- und Betriebslösungen entstehen gerade erst und sind oft eher stark technologisierten Unternehmen bekannt und zugänglich. Wer auf diese Art baut, sollte den Betrieb und dessen Beherrschbarkeit und die Engpässe also von Anfang an mitdenken.

Das Datenproblem bleibt. KI kann eine SAP-Integration genauso schreiben wie ein Kalkulationswerkzeug, die Dokumentation ist lange verfügbar, umfangreich und gut erschlossen. Die technische Anbindung ist aus meiner Erfahrung selten das Engpass-Thema. Eher die Frage, ob die Daten überhaupt strukturiert vorliegen und ob jemand im Unternehmen weiß, wo welche Daten sind und ob sie aktuell sind. Artikelstammdaten in drei verschiedenen Excel-Listen, Systemfreigaben im Kopf des Außendienstlers, Preislisten als PDF-Anhang im Postfach des Einkäufers: Für diese Lücke sehe ich keine rein technische Antwort, sie liegt im Organisatorischen. Und mit “strukturiert” meine ich nicht für KI aufbereitet, sondern schlicht maschinenlesbar und konsistent gepflegt, sodass Menschen wie Werkzeuge damit arbeiten können, ganz unabhängig von KI.

Hier löst sich für mich der scheinbare Widerspruch auf: Der Hebel ist am größten, wo die Not am größten ist, also gerade im wenig digitalisierten Bau. Angepackt wird er aber zuerst dort, wo ein Unternehmen die Vorarbeit erledigt und seine Daten strukturiert und digital bereitstellt. Das ist keine Aufgabe, die man sich nur von außen holt, sondern eine konsequente, oft weitreichende Entscheidung des Unternehmens selbst. Denn sie betrifft nicht selten lange etablierte Verhaltensweisen und Prozesse, die kein LLM und keine Zeile Code ändern. Ohne diese Entscheidung und ohne Konsequenz bleibt der Hebel der neuen Möglichkeiten klein, so groß die Not auch ist.

Die eigentliche Frage

Für Geschäftsführer in der beispielhaft gewählten Baustoffbranche entsteht aus meiner Sicht eine neue Chance, die auch auf andere Branchen übertragbar ist: Ein Werkzeug, das vor einem Jahr noch zu aufwändig gewesen wäre, ist auf einmal in Reichweite. Die Frage, die ich am Ende stellen würde, lautet nicht mehr “Lohnt sich der Aufwand?”, sondern “Welches unserer Probleme ist zum ersten Mal lösbar und was bedeutet das für unsere Prozesse und Verhaltensweisen?”

Damit verschiebt sich für mich auch der Charakter der Entscheidung, weg vom klassischen Abwägen zwischen Standardsoftware und Eigenentwicklung, hin zu einer Priorisierungsentscheidung: Welches der zehn Probleme, die wir seit Jahren mit Excel und Telefon bearbeiten, hat den größten wirtschaftlichen Wert, wenn wir es in beispielsweise vier Wochen individuell lösen könnten?

Die Antwort wird für jeden Hersteller eine andere sein. Vielleicht ist das kein Mangel, sondern der eigentliche Punkt: Individualsoftware war immer für genau diese Spezialfälle gedacht. Sie war nur zu lange zu aufwändig.

Wesentliche Erkenntnisse

1 — Das Long-Tail-Prinzip auf die Softwareentwicklung angewendet

Vor zwanzig Jahren machten sinkende Vertriebskosten das Nischenprodukt wirtschaftlich. Denselben Effekt sehe ich jetzt bei sinkenden Entwicklungskosten: nicht mehr nur das Nischenprodukt, sondern die Softwarelösung mit Stückzahl 1 rückt in den Bereich des Wirtschaftlichen. Dadurch verschiebt sich die Grenze dessen, was sich wirtschaftlich lohnt, erheblich.

2 — Der Gewinn hängt am Prozess, nicht am Werkzeug

Dieselben Werkzeuge machen im alten Ablauf, in dem am Ende doch wieder ein Mensch alles durchsehen muss, eher langsamer statt schneller. Der Sprung kommt erst mit verändertem Vorgehen: den Agenten einen engen Rahmen aus Vorgaben und Prüfungen setzen und dem Ergebnis darin vertrauen, statt alles selbst nachzulesen. KI verschiebt die Arbeit vom Schreiben und Prüfen von Code hin zum Setzen dieses Rahmens.

3 — Standards regeln nur eine von drei Ebenen

Beim überbetrieblichen Austausch zwischen Hersteller, Handel und Handwerk hat der Bau nicht zu wenige Standards, sondern viele, die je eine Scheibe abdecken und dort aufhören: GAEB, DPB, ETIM, BIM, der Dach-Daten-Pool. Zwei Ebenen erreicht keiner von ihnen, die herstellereigene Logik, sein Unterscheidungsmerkmal jenseits jeder Standardisierung, und die eigene, über Jahre gewachsene Systemlandschaft. Jede der drei Ebenen verlangt eine eigene Individualsoftware-Antwort, und sie zu verwechseln führt in die Irre.

4 — Ein geplantes Ende ist Teil des Modells, kein Scheitern

Wenn der Neubau nur noch einen Bruchteil des früheren Aufwands kostet, verliert die alte Angst vor der Individualsoftware-Leiche im Keller ihre Grundlage. Solche Lösungen bekommen einen geplanten Lebenszyklus von 12 bis 24 Monaten: nutzen, amortisieren, neu bauen. Zum Risiko wird nicht der Neubau, sondern das Festhalten an einem System, das sich mit weniger Aufwand neu bauen ließe. Das trägt aber nur, wenn der Softwarebetrieb genauso automatisiert wird wie das Bauen. Ansonsten wird die Summe vieler kleiner Systeme selbst zum Engpass.

5 — Der Hebel ist am größten, wo die Not am größten ist, einlösbar zuerst, wo die Daten stimmen

Die technische Anbindung ist selten das Engpass-Thema, die Dokumentation großer Systeme ist alt und gut erschlossen. Der Engpass ist, ob die Daten maschinenlesbar und konsistent gepflegt vorliegen und ob jemand im Haus weiß, wo sie sind und was sie bedeuten. So löst sich der scheinbare Widerspruch: Gerade der wenig digitalisierte Bau hat den größten Hebel, aber einlösen kann ihn zuerst, wer die Daten vorher in Ordnung bringt. Das ist eine Entscheidung des Unternehmens, keine, die man einkauft.

„SaaSpocalypse”: Bezeichnung für den Kurssturz von Software-Aktien im Jahr 2026, ausgelöst durch die Sorge, dass KI-Agenten das Modell der Lizenz pro Nutzer ablösen; Software-Werte verloren im Jahresverlauf deutlich (Berichte nennen mehrere hundert Milliarden US-Dollar Marktwert). Quelle: Peter Cohan, „SaaSpocalypse Now? AI Is Disrupting SaaS — But Not All Software Is Doomed”, Forbes, Februar 2026. https://www.forbes.com/sites/petercohan/2026/02/06/saaspocalypse-now-ai-is-disrupting-saas---but-not-all-software-is-doomed/ ↩
Alex Immerman, Santiago Rodriguez, „Good news: AI Will Eat Application Software”, Andreessen Horowitz (a16z), 2. März 2026 → Gegenposition zur SaaSpocalypse: KI vergrößere die Software-Branche, statt sie zu zerstören; der Wert habe nie primär im Code gelegen, sondern in Wechselkosten, Netzwerkeffekten, Daten und eingebettetem Prozesswissen. https://a16z.com/good-news-ai-will-eat-application-software/ ↩
Quelle: IW Köln / BMWK, „Digitalisierungsindex 2024” (Kurzfassung, Abb. 3) → Die Branchengruppe „Baugewerbe, Ver- und Entsorgung” liegt mit 67,6 Indexpunkten auf dem letzten Platz aller sieben Branchengruppen (Spitze IKT 285,1; Gesamtwirtschaft 113,6). Der Bau ist mit Ver- und Entsorgung gebündelt, nicht separat ausgewiesen. https://www.iwkoeln.de/fileadmin/user_upload/Studien/Gutachten/PDF/2024/Ergebnisbericht_Digitalisierungsindex_2024_Kurzfassung.pdf ↩
Quelle: Eurostat, „Large businesses make up only 0.2% of EU enterprises” (Structural Business Statistics, Referenzjahr 2023) → Der Bausektor stellt rund vier Millionen (12 %) aller EU-Unternehmen. Dass davon rund 95 % weniger als 20 Beschäftigte haben, ist eine FIEC-Angabe (European Construction Industry Federation), nicht Eurostat. https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20241205-1 ↩
Quelle: Heinze GmbH, Umfrage unter Baustoff-Fachhändlern zum DPB-Branchenstandard (über 90 Einzelinterviews, Herbst 2022) → Excel ist mit über 90 % das häufigste Austauschformat; 69 % der Fachhändler holen fehlende Stammdaten weiterhin direkt beim Lieferanten ein, obwohl ein Lieferantenportal existiert. https://www.heinzemedien.de/artikeldaten-im-dpb-branchenstandard-umfrage-unter-baustoff-fachhaendlern/ ↩