Was kostet Individualsoftware, und welche Faktoren treiben den Aufwand?

Was kostet Individualsoftware bei uns?

Stufe	Was es ist	Rahmen (zzgl. MwSt.)
Erstgespräch	30 Minuten, danach eine Seite schriftliche Einschätzung	kostenlos
Analyse	Abläufe und Daten ansehen, schriftlicher Plan mit Aufwand und Nutzen	ab 1.200 €
Machbarkeits-Sprint (Proof of Concept)	prüft an echten Daten, ob es trägt, und endet mit etwas Lauffähigem, dazu Aufwandsrahmen und Etappenplan	5.000–10.000 €
KI-Funktion oder Automatisierung an einem bestehenden System	ein Ablauf, ein oder zwei Schnittstellen, etwa Belege auslesen und ins ERP schreiben	5.000–20.000 €
Eigene Anwendung oder individuelle Software	eigene Anwendung für einen Ablauf, mehrere Rollen und Anbindungen, etwa eine Angebotsstrecke oder eine Field-Service-App	10.000–80.000 €
Betrieb und Weiterentwicklung	eigener Vertrag: Hosting in Deutschland, Updates, Anpassungen	15–25 % der Entwicklungskosten pro Jahr, je nach Vertragsumfang

Das sind die Spannen, in denen unsere Vorhaben typischerweise liegen, keine Preisliste. Den Festpreis gibt es je Etappe, sobald der Umfang feststeht.

Individualsoftware ist Software, die für einen bestimmten Ablauf gebaut statt als Standardprodukt gekauft wird. Eine Preisliste je Funktion gibt es dafür nicht, weil der Preis am Zuschnitt hängt. Dieselbe Beschreibung, etwa „ein Tool für unsere Einsatzplanung“, kann ein Vorhaben von wenigen Wochen sein oder eines von vielen Monaten.

Was sich dagegen seriös beantworten lässt: welche Faktoren den Aufwand treiben. Wer die kennt, kann eine Anfrage so stellen, dass eine belastbare Einschätzung überhaupt möglich wird, und erkennt Angebote, die zu billig kalkuliert sind, bevor er sie unterschreibt.

Warum gibt es Spannen, aber keine Preisliste?

Weil die Frage „Was kostet Individualsoftware?“ ungefähr so präzise ist wie „Was kostet ein Hausumbau?“. Die Antwort ist eine Gegenfrage: an welchem Haus, mit welchem Bestand, mit welchen Auflagen.

Wer einen Festpreis nennt, bevor er den Ablauf gesehen hat, macht eines von drei Dingen: Er kalkuliert den Standardfall und rechnet nach, sobald die Besonderheiten auftauchen. Er kalkuliert den schlimmsten Fall und ist für viele Anfragen zu teuer. Oder er verkauft in Wahrheit ein Standardprodukt mit einer Individual-Etikette.

Der Weg, der funktioniert, ist ein anderer: erst die Analyse und, wo es technisch offen ist, ein Machbarkeits-Sprint, der die offenen Fragen an echten Daten klärt und mit einem lauffähigen Ergebnis endet. Danach lässt sich der Rest beziffern, mit einer Grundlage statt mit einer Schätzung.

Welche sechs Faktoren treiben den Aufwand bei Individualsoftware?

Faktor	Aufwand steigt, wenn	Früh erkennbar an
Angebundene Systeme	Daten aus mehreren Systemen gelesen und in andere geschrieben werden	der Liste der Systeme, die mitspielen müssen
Sauberkeit der Daten	Dubletten, Freitext und ungeschriebene Konventionen im Bestand stecken	der Frage, welches System die führende Quelle ist
Sonderfälle im Ablauf	Ausnahmen erst während des Baus auftauchen	der Zahl der Sonderfälle, die sich vorab benennen lassen
Offline-Betrieb	vor Ort keine Verbindung besteht und später abgeglichen werden muss	dem Einsatzort, etwa einem Technikraum ohne Netz
Rollen und Rechte	verschiedene Gruppen jeweils anderes sehen und ändern dürfen	der Zahl der Gruppen, die damit arbeiten
Entscheidung auf Kundenseite	jede Frage in eine Runde muss	einer Person, die fachlich entscheiden darf

1. Wie viele Systeme hängen dran?

Der größte Hebel, und er wird fast immer unterschätzt. Eine Anwendung, die für sich steht, ist überschaubar. Dieselbe Anwendung, die Daten aus einem ERP zieht, in eine Warenwirtschaft schreibt und Termine mit einem Kalender abgleicht, ist ein anderes Vorhaben. Der Grund ist alles, was um die Übertragung herum gebaut werden muss: Feldabbildung, Wiederholversuche, Protokoll, Meldung an einen Menschen, wenn etwas hängen bleibt.

Faustregel aus unseren Projekten: Jedes zusätzliche System, das mitspielen muss, kostet mehr als die Funktion selbst, die es anbindet.

2. Wie sauber sind die Daten?

Der Bestand entscheidet über den Aufwand. Gewachsene Datenbestände enthalten Dubletten, Freitextfelder, in denen strukturierte Information steckt, und Konventionen, die nur im Kopf einer Person existieren. Das ist normal, aber es ist Arbeit, und zwar Arbeit, die vor der eigentlichen Entwicklung anfällt.

Woran man es früh erkennt: Wenn niemand im Haus sagen kann, welches System die führende Quelle für eine bestimmte Information ist, wird die Bereinigung ein eigener Posten.

3. Wie viele Sonderfälle kennt der Ablauf?

„Im Prinzip läuft das immer gleich“ ist der teuerste Satz in jedem Erstgespräch. Die Ausnahmen sind selten das Problem. Das Problem ist, dass sie erst auftauchen, wenn schon gebaut wird. Ein Prozess mit drei benannten Sonderfällen ist gut kalkulierbar. Ein Prozess, bei dem im Bau der vierte, fünfte und sechste dazukommt, ist es nicht.

4. Muss es offline funktionieren?

Ein Beispiel aus einem eigenen Projekt: Für die Field-Service-Software, die wir für zwei Kunden aus der Tor- und Zutrittstechnik gebaut haben, ist der Offline-Betrieb der Normalfall, im Technikraum steht keine Verbindung. Das bedeutet lokale Datenhaltung, einen Abgleich nach der Rückkehr ins Netz und eine Antwort auf die Frage, was passiert, wenn zwei Leute dieselbe Anlage bearbeitet haben.

Offline-Fähigkeit ist ein echter Aufwandstreiber. Sie lohnt sich, wo sie gebraucht wird, und sollte weggelassen werden, wo nicht.

5. Wie viele Rollen und Rechte gibt es?

Eine Anwendung, in der alle dasselbe dürfen, ist deutlich schneller gebaut als eine, in der Monteure, Innendienst, Leitung und externe Partner jeweils anderes sehen und ändern dürfen. Rechtelogik ist unspektakulär und zieht sich durch jede einzelne Ansicht.

6. Wer entscheidet auf Kundenseite?

Der einzige Faktor, der nichts mit Technik zu tun hat, und trotzdem einer der wirksamsten. Wenn es eine Person gibt, die fachlich entscheiden darf, läuft ein Projekt. Wenn jede Frage in eine Runde muss, wächst die Laufzeit, ohne dass eine Zeile mehr Code entsteht. Deshalb steht „eine intern verantwortliche Person“ bei uns unter den Kriterien dafür, ob ein Vorhaben überhaupt passt.

Was lässt sich vor einem Softwareprojekt klären, und was nicht?

Vorab klärbar ist mehr, als die meisten denken: Ob die Daten das hergeben, was der Ablauf braucht. Ob die beteiligten Systeme einen brauchbaren Weg hinein und hinaus haben. Ob die Erkennungsquote bei einem KI-Thema an echten Belegen ausreicht. Ob der erste sinnvolle Ausschnitt klein genug ist, um früh etwas Lauffähiges zu haben.

Nicht vorab klärbar ist, wie sich ein Ablauf über Monate im Betrieb verhält, und welche Sonderfälle erst auftauchen, wenn echte Leute mit echten Daten arbeiten. Deshalb bauen wir in Etappen mit festem Umfang statt in einem Gesamtpaket: Jede Etappe endet mit etwas, das läuft, und die nächste wird auf Basis dessen zugeschnitten, was man dann weiß.

Woran erkennt man ein realistisches Angebot für Individualsoftware?

Drei Dinge, an denen sich ein belastbares Angebot erkennen lässt, unabhängig davon, von wem es kommt:

• Es benennt, was nicht drin ist. Ein Angebot ohne Abgrenzung ist eine Wette.
• Es hat eine Etappenstruktur. Ein einziger Preis für ein halbes Jahr Arbeit bedeutet, dass jemand geraten hat.
• Es sagt, was passiert, wenn eine Annahme nicht hält.

Ein viertes gibt den Ausschlag: Vor dem Angebot sollte etwas Lauffähiges stehen: ein Skript, eine ausführbare Datei, ein Klickdummy, den man selbst startet und mit eigenen Daten füttert. Dafür gibt es bei uns den Machbarkeits-Sprint, typischerweise 5.000–10.000 €.

Welche Angaben braucht eine erste Kostenschätzung?

Wer wissen will, in welcher Größenordnung ein Vorhaben liegt, braucht drei Angaben zur Hand: welche Systeme mitspielen müssen, wie viele Leute in dem Ablauf beteiligt sind, und ob es eine Person gibt, die entscheiden darf. Damit lässt sich im Erstgespräch schon einiges einordnen, deutlich mehr jedenfalls als mit einer Preisliste je Funktion.