Ich baue seit fast 20 Jahren Software, die unter anspruchsvollen Rahmenbedingungen bestehen muss.

Ich komme aus dem Innviertel in Oberösterreich. Mein Interesse an Softwareentwicklung begann 2002 mit dem Map-Editor von Warcraft 3 — dem ersten Werkzeug, mit dem ich etwas bauen konnte, das auch andere benutzen.

Beruflich angefangen hat alles in Systemhäusern — parallel dazu habe ich berufsbegleitend Software Engineering an der FH Hagenberg studiert. Theorie und Praxis liefen also von Anfang an nebeneinander her: Was ich am Wochenende gelernt hatte, stand unter der Woche auf dem Prüfstand einer echten Kundenanforderung.

In diesen Jahren habe ich ERP-Systeme entwickelt und in Betrieb genommen — von der einzelnen Anwendung für eine Abteilung bis zum System für ein ganzes Unternehmen. Ich habe solche Projekte also selbst durchgeführt und kenne die Gründe, aus denen sie teuer und langwierig werden. Ein Schwerpunkt lag dabei auf der Performance: Es wird unterschätzt, wie viel Arbeitszeit ein System zurückgibt, wenn jeder Mausklick sofort eine Handlung auslöst, statt minutenlang zu warten. Über eine ganze Abteilung summiert sich das erheblich — und anders als neue Funktionen merkt das jeder sofort.

Später war ich im Maschinenbau und in einem Industriebetrieb als Software-Architekt tätig — noch nicht als Dienstleister, sondern angestellt im Unternehmen selbst. Ein Teil dieser Systeme läuft bis heute reibungslos, der Rest wurde weiterentwickelt.

Seit 2017 bin ich selbstständig und führe die masp-software gmbh. In dieser Zeit habe ich eigene Entwicklerteams aufgebaut — bis zu zehn Personen, samt der Entwicklungsprozesse dahinter. Und ich habe sie finanziert. Ich weiß also nicht nur, wie man ein Team zum Laufen bringt, sondern auch, was es kostet und wo das Geld verloren geht.

Quer durch alle diese Stationen zogen sich dieselben Branchen: Automobilindustrie und Zulieferer, Maschinenbau, Elektronikfertigung, Gießereien, Luftfahrt. Und immer dieselbe Art von Aufgabe — dort, wo Software auf reale Prozesse trifft: an der Anlage, in der Prüfung, im Lager, an der Schnittstelle zwischen zwei Systemen, die nie dafür gedacht waren, miteinander zu sprechen.

Inhaltlich ging es fast immer um zwei Bereiche, die als unangenehm gelten: Qualitätssicherung und Schnittstellenwesen. Dahinter stand immer dasselbe Ziel — Transparenz über den laufenden Prozess und damit die Möglichkeit, ihn zu lenken, statt ihm hinterherzulaufen. Beide Bereiche verzeihen keine Nachlässigkeit in der Architektur: Man merkt sie nicht beim Programmieren, sondern zwei Jahre später oder durch wiederkehrende Produktionsstillstände, wenn niemand mehr weiß, warum etwas so gebaut wurde.

Genau daraus ist meine Haltung entstanden: Der schwierige Teil an Software ist nicht das Schreiben von Code. Der schwierige Teil ist die Entscheidung darüber,was gebaut wird und wie es zusammenhängt.

Heute baue ich wieder Teams auf — für mich und für meine Kunden. Diesmal mit AI. Mit demselben Anspruch an Architektur, Richtlinien und Qualität, den ich an ein Team aus Menschen gestellt habe. Dabei gilt eine Bedingung, die ich für nicht verhandelbar halte: Diese Teams sind so gebaut, dass Menschen verstehen, was entsteht — und jederzeit mitarbeiten können. Eine Entwicklung, die nur die AI selbst durchschaut, wäre genau die Blackbox, die Sie nicht wollen. Ich übrigens auch nicht.

Was ich Ihnen empfehle, mache ich also gerade selbst.

Über Jahre habe ich dieselbe Situation immer wieder gesehen: Ein Fachbereich weiß genau, was er braucht. Die interne IT kommt nicht nach. Ein externes Angebot ist sechsstellig und dauert ein Jahr. Also entsteht wieder eine Excel-Datei, die nur eine Person versteht.

Der eigentliche Engpass war nie das Wissen über den Prozess — das liegt im Unternehmen. Der Engpass war immer die Umsetzung: zu teuer, zu langsam, zu weit weg vom Fachbereich.

Genau dieser Engpass ist weggefallen. AI-gestützte Entwicklung hat die Codearbeit so stark beschleunigt und verbilligt, dass Individualsoftware für Betriebe wirtschaftlich wird, für die sie es nie war. Was dabei nicht automatisch mitkommt, ist die Architektur — die Entscheidung, was richtig gebaut wird, damit das System in fünf Jahren noch trägt.

Diesen Teil übernehme ich. Bis Sie ihn selbst übernehmen können.

Ich bin ein Macher. Mir ist wichtiger, dass etwas läuft, als dass es lange besprochen wurde.

Ich bin direkt und ergebnisorientiert. Wenn ein Weg nicht funktioniert, sage ich das — auch dann, wenn es der Weg ist, den Sie bereits eingeschlagen haben. Das ist im ersten Moment unbequem und erspart Ihnen im zweiten viel Geld.

Und mein Maßstab ist nicht, ob ein Projekt abgeschlossen wurde. Mein Maßstab ist, ob Sie durch meine Arbeit erfolgreicher sind als vorher.