Warum es keine pauschale Antwort gibt
“Was kostet Individualsoftware?” ist eine der Fragen, die wir am häufigsten hören, direkt gefolgt von der Erwartung einer Zahl. Die ehrliche Antwort ist: Es kommt darauf an, und zwar auf mehr Faktoren, als sich in einer Preistabelle abbilden lassen.
Individualsoftware ist per Definition kein Produkt von der Stange. Zwei Projekte mit derselben Bezeichnung, etwa “Auftragsverwaltung” oder “internes Tool”, können komplett unterschiedliche Aufwände bedeuten, je nachdem, wie viele Systeme angebunden werden müssen, wie viele Nutzerrollen es gibt und wie stabil die Anforderungen tatsächlich sind. Wer dir ohne dieses Wissen eine feste Zahl nennt, rät entweder, oder die Zahl gilt nur für ein Projekt, das mit deinem wenig zu tun hat.
Das heißt nicht, dass sich die Frage nicht seriös beantworten lässt. Sie lässt sich nur nicht pauschal beantworten, sondern nur für dein konkretes Projekt. Was sich dagegen pauschal erklären lässt, sind die Faktoren, die den Aufwand treiben, und genau die schauen wir uns hier an.
Was die Kosten wirklich treibt
Umfang und Funktionstiefe
Der offensichtlichste Faktor, aber auch der am häufigsten unterschätzte. Ein einfaches internes Tool mit einer Handvoll Ansichten ist etwas anderes als ein System, das mehrere Nutzerrollen, Genehmigungsprozesse und Reporting abbilden muss. Der Unterschied liegt oft nicht in der ersten Version, die meist überschaubar wirkt, sondern in dem, was in den Wochen danach als “eigentlich noch wichtig” dazukommt.
Integrationskomplexität
Individualsoftware entsteht selten im luftleeren Raum. Sie muss mit einem bestehenden ERP-System sprechen, Daten aus einer Buchhaltungssoftware ziehen oder in eine Warenwirtschaft schreiben. Jede zusätzliche Schnittstelle bringt eigenen Aufwand mit, vor allem wenn die Gegenstelle keine saubere API hat oder die Dokumentation veraltet ist, was bei gewachsenen Systemen der Normalfall ist.
Teamzusammensetzung
Ein Projekt, das nur Backend-Logik braucht, ist anders zu bepreisen als eines mit aufwendigem Frontend, mobiler Nutzung oder eigener Infrastruktur. Wie viele unterschiedliche Rollen ein Projekt braucht, von Architektur über Entwicklung bis Betrieb, wirkt sich direkt auf den Aufwand aus, nicht nur auf die Anzahl der Personen.
Zeitdruck und Dringlichkeit
Ein Projekt, das in drei Monaten produktiv sein muss, weil ein Altsystem zum Stichtag abgeschaltet wird, hat andere Rahmenbedingungen als eines, das in Ruhe über ein Jahr wachsen darf. Dringlichkeit verändert nicht nur den Zeitplan, sie verändert auch, wie viel parallel statt nacheinander gearbeitet werden muss, und das hat einen Preis.
Wartung und Betrieb nach dem Go-live
Der Faktor, der in den meisten ersten Gesprächen fehlt. Software, die läuft, braucht danach jemanden, der sie beobachtet, Fehler behebt und mit den Anforderungen des Geschäfts mitwachsen lässt. Wer nur die Entwicklungskosten bis zum Launch einplant und den Betrieb danach ignoriert, plant nur die halbe Rechnung.
Warum wir keine Festpreise nennen
Es gibt Anbieter, die mit “Individualsoftware ab X €” werben. Das klingt nach Klarheit, ist aber meistens ein Marketingversprechen, kein belastbares Angebot. Ein echter Festpreis setzt voraus, dass der Funktionsumfang zu Beginn vollständig feststeht, und genau das ist bei den wenigsten Individualsoftware-Projekten der Fall. Anforderungen ändern sich, sobald ein erster funktionierender Ausschnitt läuft und echte Nutzung zeigt, was tatsächlich gebraucht wird.
Ein Festpreis auf Basis unvollständiger Anforderungen führt zu einem von zwei Ergebnissen: Entweder wird der Umfang so eng definiert, dass jede spätere Änderung als teurer Nachtrag verkauft wird, oder der Preis wird von Anfang an mit einem Puffer für das Unbekannte kalkuliert, den am Ende du bezahlst, unabhängig davon, ob er gebraucht wurde. Beides ist ehrlicher gesagt keine Kostensicherheit, sondern nur eine verschobene Unsicherheit.
Wir arbeiten deshalb in Wochenzyklen mit sichtbarem Fortschritt. Du siehst früh, was entsteht, wir passen Umfang und Kurs an, bevor sich Fehlentscheidungen festsetzen, und der Aufwand bleibt jederzeit nachvollziehbar, statt hinter einer pauschalen Zahl versteckt zu sein.
Wie wir ein Projekt tatsächlich einschätzen
Statt einer Zahl aus der Ferne beginnt jedes Projekt mit einer Analyse. Wir schauen uns dein Geschäftsproblem an, nicht nur die gewünschte Funktion, und klären, was die Software wirklich leisten muss, bevor überhaupt über Umsetzung gesprochen wird. Erst danach legen wir fest, wie das System aufgebaut ist, also die Architektur, bevor die erste Zeile Code geschrieben wird.
Die Umsetzung selbst läuft in wöchentlichen Zyklen, mit sichtbarem Fortschritt nach den ersten zwei Wochen, sodass du früh siehst, wofür du bezahlst. Am Ende steht nicht nur ein Launch, sondern der Betrieb: Wir bringen das System in Produktion und betreiben es, solange du uns brauchst, statt es nach der Übergabe seinem Schicksal zu überlassen.
Das ist der Grund, warum wir mit einem kostenlosen Architektur-Review starten, statt mit einer geschätzten Zahl. Erst wenn wir dein Problem und deine Systemlandschaft kennen, lässt sich seriös sagen, wie groß der Aufwand tatsächlich ist, und welche der oben genannten Faktoren bei dir am stärksten ins Gewicht fallen.