Individuelle Software entwickeln lassen: Was Unternehmen prüfen sollten

Individuelle Software kann Abläufe vereinfachen, manuelle Arbeit reduzieren und Prozesse abbilden, für die Standardlösungen nicht ausreichen. Gleichzeitig bindet ein Entwicklungsprojekt häufig erhebliches Budget und schafft technische Abhängigkeiten über viele Jahre. Bevor Unternehmen individuelle Software entwickeln lassen, sollten deshalb nicht nur Funktionen und Preis, sondern auch Anbieter, Architektur, Vertragsbedingungen und spätere Handlungsfreiheit geprüft werden.

Wann lohnt es sich, individuelle Software entwickeln zu lassen?

Individualsoftware ist kein Selbstzweck. Für viele Standardprozesse sind etablierte SaaS- oder Branchenlösungen wirtschaftlich sinnvoller. Eine Eigenentwicklung wird vor allem dann interessant, wenn Standardsoftware regelmäßig an die Grenzen der tatsächlichen Unternehmensprozesse stößt.

Typische Anzeichen sind mehrere parallel genutzte Systeme, wiederkehrende Übertragungen zwischen Excel, CRM und Fachsoftware, manuelle Arbeitsschritte oder Prozesse, die nur durch zahlreiche Plugins und Sonderlösungen funktionieren.

Auch ein digitales Geschäftsmodell kann eine Eigenentwicklung erforderlich machen. Dazu gehören beispielsweise Kundenportale, interne Plattformen, Konfiguratoren, SaaS-Produkte oder Systeme mit eigener Bewertungs-, Abrechnungs- oder Prozesslogik.

Die entscheidende Frage lautet deshalb zunächst nicht: Was soll programmiert werden? Sondern: Welches konkrete betriebliche Problem soll gelöst werden?

Diese Unterscheidung ist wichtig. Wer mit einer langen Funktionsliste in die Anbietersuche geht, hat möglicherweise bereits eine technische Lösung definiert, bevor das eigentliche Problem ausreichend verstanden wurde.

Anforderungen klären, bevor Angebote eingeholt werden

Viele Schwierigkeiten bei Softwareprojekten entstehen bereits vor der ersten Zeile Code. Anforderungen sind unvollständig, unterschiedliche Fachbereiche verfolgen verschiedene Ziele oder Funktionen werden beschrieben, ohne die zugrunde liegenden Geschäftsprozesse vollständig abzubilden.

Vor einer Ausschreibung oder Angebotsanfrage sollten Unternehmen deshalb zumindest klären:

• welche Prozesse das System abbilden soll

• welche Nutzergruppen damit arbeiten

• welche Daten verarbeitet werden

• welche bestehenden Systeme angebunden werden müssen

• welche Rollen und Berechtigungen erforderlich sind

• welche manuellen Tätigkeiten entfallen sollen

• welche Anforderungen zwingend und welche optional sind

Dabei müssen noch nicht sämtliche Details eines späteren Lastenhefts feststehen. Der Anbieter sollte ausreichend Raum für fachliche Konzeption haben. Der wirtschaftliche Zweck des Projekts muss jedoch eindeutig sein.

Andernfalls vergleichen Unternehmen später Angebote für unterschiedliche Lösungen, obwohl diese auf den ersten Blick ähnlich aussehen.

Softwareangebote sind häufig nur scheinbar vergleichbar

Ein Angebot über 40.000 Euro und ein Angebot über 90.000 Euro müssen keineswegs dieselbe Leistung enthalten.

Der Unterschied kann beispielsweise darin liegen, ob Konzeption, UX, Datenmigration, Schnittstellen, Tests, Dokumentation, Projektmanagement, Deployment und Schulung enthalten sind.

Besonders kritisch sind pauschale Positionen wie:

„Entwicklung Kundenportal“

oder

„Umsetzung gemäß Anforderung“

Solche Formulierungen lassen erheblichen Interpretationsspielraum.

Bei einem belastbaren Angebot sollte nachvollziehbar sein, welche Leistungen enthalten sind, welche Annahmen der Kalkulation zugrunde liegen und welche Leistungen ausdrücklich nicht Bestandteil des Angebots sind.

Wer ein umfangreicheres Entwicklungsprojekt vergeben möchte, sollte deshalb nicht ausschließlich den Gesamtpreis vergleichen. Entscheidend ist der tatsächliche Leistungsumfang hinter dem Preis.

Ein konkretes Entwicklungsangebot kann vor Vertragsabschluss auch im Rahmen einer unabhängigen Vertrags- und Angebotsprüfung fachlich und wirtschaftlich eingeordnet werden.

Den Softwareentwickler nicht nur nach Referenzen auswählen

Eine überzeugende Website und bekannte Kundenlogos beantworten noch nicht die entscheidende Frage: Kann dieser Anbieter genau das geplante System zuverlässig entwickeln und langfristig betreuen?

Referenzen sollten deshalb genauer betrachtet werden.

Interessant ist beispielsweise:

Welche Teile eines genannten Projekts hat der Anbieter tatsächlich selbst umgesetzt?

War er für die komplette technische Architektur verantwortlich oder lediglich für einzelne Entwicklungsleistungen?

Ist das Projekt heute produktiv im Einsatz?

Wie komplex ist es im Vergleich zum geplanten Vorhaben?

Wer hat das System nach dem Launch weiterentwickelt?

Gerade bei kleineren Softwareagenturen hängt die Qualität außerdem stark von einzelnen Personen ab. Unternehmen sollten deshalb wissen, wer das Projekt tatsächlich entwickelt und nicht nur, wer es verkauft.

Bei größeren Investitionen kann es sinnvoll sein, einen potenziellen Dienstleister vor der Vergabe unabhängig zu prüfen. AVERVO unterscheidet dabei bewusst zwischen einem Anbieter fertiger Software und einem individuellen Entwicklungsprojekt. Für klassische SaaS- oder Standardsoftware steht beispielsweise die Softwareanbieter-Prüfung zur Verfügung.

Architektur entscheidet über spätere Kosten

Eine funktionierende Oberfläche sagt wenig über die Qualität einer Software aus.

Zwei Systeme können für Nutzer nahezu identisch aussehen und technisch vollkommen unterschiedlich aufgebaut sein. Die Folgen zeigen sich häufig erst später: Änderungen werden teuer, neue Funktionen verursachen Fehler oder einzelne Bestandteile lassen sich kaum noch erweitern.

Vor größeren Projekten sollte deshalb geklärt werden, nach welchen Grundprinzipien der Anbieter Datenmodell, Benutzerrechte, Schnittstellen und Systemarchitektur plant.

Besonders kritisch wird es, wenn die technische Struktur erst während der Entwicklung nebenbei entsteht.

Bei komplexeren Anwendungen sollte die Architektur der Oberfläche vorausgehen. Datenstrukturen, Rollen, zentrale Geschäftslogik und relevante Integrationen sollten zumindest konzeptionell geklärt sein, bevor große Teile des Systems entwickelt werden.

Quellcode und Nutzungsrechte müssen eindeutig geregelt sein

Eine der wichtigsten Fragen wird erstaunlich häufig erst gestellt, wenn das Projekt bereits läuft:

Wem gehört die entwickelte Software?

Unternehmen sollten vor Vertragsabschluss klären, welche Nutzungsrechte sie erhalten und ob sie Zugriff auf den vollständigen Quellcode besitzen.

Dabei geht es nicht nur um juristisches Eigentum. Entscheidend ist die tatsächliche Handlungsfähigkeit.

Kann ein anderes Entwicklungsteam das Projekt übernehmen?

Sind Repository und Entwicklungsumgebung zugänglich?

Sind verwendete Drittanbieter-Komponenten dokumentiert?

Gibt es Lizenzbestandteile, die einen Anbieterwechsel erschweren?

Ein Softwareprojekt sollte im Idealfall nicht allein deshalb beim ursprünglichen Entwickler bleiben müssen, weil niemand anderes das System verstehen oder betreiben kann.

Vendor Lock-in bereits vor Projektbeginn vermeiden

Eine gewisse Bindung an einen Entwickler lässt sich bei Individualsoftware kaum vollständig vermeiden. Ein Anbieter, der ein System mehrere Jahre entwickelt hat, verfügt zwangsläufig über Wissen, das ein neuer Dienstleister zunächst aufbauen müsste.

Problematisch wird daraus ein Vendor Lock-in, wenn ein Wechsel technisch oder organisatorisch faktisch unmöglich wird.

Deshalb gehören Quellcodezugriff, Dokumentation und Übergabefähigkeit zu den zentralen Prüfpunkten vor einer Beauftragung.

Wie unterschiedlich Anbieter damit umgehen, zeigt beispielsweise IROBA bei der individuellen Softwareentwicklung. Dort werden vollständiges Eigentum an Quellcode und Daten sowie eine Dokumentation des Systems ausdrücklich als Bestandteil des Modells beschrieben.

Für Auftraggeber ist weniger entscheidend, welcher Anbieter diese Zusage macht. Entscheidend ist, ob sie im konkreten Angebot und später im Vertrag tatsächlich nachvollziehbar geregelt ist.

Eine Aussage auf einer Website ersetzt keine vertragliche Vereinbarung.

Dokumentation ist Teil der Software

Dokumentation wird in Softwareprojekten häufig als Nebenthema betrachtet. Für den langfristigen Wert eines Systems ist sie jedoch erheblich.

Eine Individualsoftware kann zehn Jahre oder länger genutzt und mehrfach erweitert werden. In dieser Zeit wechseln Mitarbeiter, Entwickler und möglicherweise auch Dienstleister.

Wichtige Architekturentscheidungen, Datenmodelle, Schnittstellen und zentrale Geschäftsregeln müssen deshalb nachvollziehbar dokumentiert sein.

Unternehmen sollten vor der Vergabe klären:

• welche technische Dokumentation erstellt wird

• wann diese aktualisiert wird

• wo sie gespeichert wird

• wer darauf Zugriff hat

• ob ein neuer Entwickler damit tatsächlich weiterarbeiten könnte

Eine gute Dokumentation reduziert nicht nur die Abhängigkeit. Sie senkt langfristig auch den Aufwand bei Fehleranalyse, Erweiterungen und Anbieterwechseln.

Festpreis oder Abrechnung nach Aufwand?

Beide Modelle können sinnvoll sein.

Ein Festpreis erhöht die Planbarkeit, funktioniert aber vor allem dann gut, wenn Leistungsumfang und Anforderungen bereits relativ klar definiert sind. Bei komplexen Projekten mit vielen offenen Fragen muss der Anbieter Unsicherheit einkalkulieren oder spätere Änderungen separat abrechnen.

Time & Material bietet mehr Flexibilität. Der Auftraggeber trägt dafür einen größeren Teil des Budgetrisikos.

Deshalb ist die Vertragsform weniger entscheidend als die Frage, wie transparent Aufwand, Fortschritt und Änderungen gesteuert werden.

Bei einer Abrechnung nach Aufwand sollten Unternehmen beispielsweise wissen:

• welche Stundensätze gelten

• welche Rollen abgerechnet werden

• wie Zeiten dokumentiert werden

• wie Budgetgrenzen funktionieren

• wann Zusatzaufwand freigegeben werden muss

• wie regelmäßig Fortschritt und Restbudget berichtet werden

Ein niedriger Stundensatz ist kein ausreichendes Auswahlkriterium. Entscheidend ist, welcher Aufwand erforderlich ist, um ein belastbares Ergebnis zu erreichen.

Schnittstellen und Datenmigration früh prüfen

Individualsoftware steht selten vollständig allein.

Bestehende Buchhaltung, Warenwirtschaft, CRM, Zahlungsanbieter, Versanddienstleister, Microsoft 365, Google Workspace oder andere Systeme müssen häufig angebunden werden.

Jede Schnittstelle erhöht die technische Komplexität.

Vor der Vergabe sollte deshalb geklärt werden, welche Systeme integriert werden müssen und ob hierfür stabile APIs zur Verfügung stehen.

Noch wichtiger ist häufig die Datenmigration.

Bestehende Daten müssen möglicherweise bereinigt, vereinheitlicht oder in ein neues Datenmodell übertragen werden. Dieser Aufwand wird bei frühen Kalkulationen leicht unterschätzt.

Die Frage „Können Sie unser bestehendes System anbinden?“ reicht deshalb nicht.

Entscheidend ist, welche Daten in welcher Qualität vorhanden sind und wie sie technisch übertragen werden können.

Datenschutz und IT-Sicherheit nicht nachträglich ergänzen

Je geschäftskritischer eine Anwendung ist, desto früher müssen Datenschutz und Sicherheit berücksichtigt werden.

Welche Anforderungen relevant sind, hängt vom konkreten Einsatzzweck ab. Ein internes Planungstool hat andere Anforderungen als ein Kundenportal mit personenbezogenen Daten oder ein System, das Zahlungsinformationen verarbeitet.

Vor der Beauftragung sollten unter anderem Hosting, Zugriffsrechte, Backups, Verschlüsselung, Protokollierung und die Verarbeitung personenbezogener Daten geklärt werden.

Auch sollte feststehen, wer auf Produktivdaten zugreifen kann und wie Entwicklungs-, Test- und Produktivumgebung voneinander getrennt werden.

Sicherheit nach Fertigstellung „noch einzubauen“ ist regelmäßig die schlechtere Lösung.

Abnahmebedingungen müssen messbar sein

Wann gilt eine Software eigentlich als fertig?

„Wenn alle Funktionen umgesetzt sind“ klingt eindeutig, ist es aber selten.

Ein Feature kann technisch vorhanden sein und trotzdem nicht zuverlässig funktionieren. Ebenso kann die Software funktional korrekt sein, aber bei realer Nutzung erhebliche Performanceprobleme verursachen.

Deshalb sollten Unternehmen vor Projektbeginn festlegen, nach welchen Kriterien Leistungen abgenommen werden.

Dazu können gehören:

• definierte Funktionsanforderungen

• Testfälle

• Rechte- und Rollenkonzepte

• Browser- oder Geräteanforderungen

• Performancewerte

• Fehlerklassen

• Dokumentationsumfang

• Datenmigration

• erfolgreiche Schnittstellentests

Je klarer diese Kriterien sind, desto geringer ist später der Interpretationsspielraum.

Betrieb und Weiterentwicklung gehören in die Kalkulation

Mit dem Go-live endet ein Softwareprojekt wirtschaftlich nicht.

Serverkosten, Monitoring, Backups, Sicherheitsupdates, Fehlerbehebung und Weiterentwicklung verursachen laufende Aufwände.

Auch externe Dienste können dauerhaft Kosten auslösen. Dazu gehören beispielsweise Cloud-Infrastruktur, E-Mail-Versand, KI-Schnittstellen, Kartenanbieter, Zahlungsdienste oder andere APIs.

Unternehmen sollten deshalb nicht nur die Entwicklungskosten betrachten, sondern die Total Cost of Ownership.

Eine Individualsoftware mit günstiger Entwicklung, aber hohem dauerhaftem Wartungsaufwand kann wirtschaftlich schlechter sein als ein zunächst teureres, technisch saubereres System.

Auch das Exit-Szenario gehört vor Vertragsabschluss auf den Tisch

Eine der sinnvollsten Fragen vor der Beauftragung lautet:

Was passiert, wenn wir in zwei Jahren nicht mehr mit diesem Anbieter zusammenarbeiten möchten?

Ein professionell geplantes Projekt sollte darauf eine konkrete Antwort haben.

Das Unternehmen benötigt dann mindestens Zugriff auf Quellcode, Daten, Dokumentation und die für den Betrieb notwendigen Zugangsdaten.

Auch Hostingaccounts, Domains, API-Konten und andere technische Assets sollten möglichst so strukturiert sein, dass das Unternehmen die Kontrolle darüber behält.

Das Exit-Szenario ist kein Ausdruck von Misstrauen. Es ist normale unternehmerische Risikovorsorge.

Was Unternehmen vor der Beauftragung prüfen sollten

Vor größeren Entwicklungsinvestitionen sollten Geschäftsführer drei Ebenen voneinander trennen.

Erstens: Ist das Vorhaben selbst sinnvoll?

Löst Individualsoftware tatsächlich ein relevantes Problem und steht der wirtschaftliche Nutzen in einem vernünftigen Verhältnis zur Investition?

Zweitens: Ist der ausgewählte Entwickler geeignet?

Passen Erfahrung, technische Kompetenz, Ressourcen und Arbeitsweise zum Projekt?

Drittens: Ist das konkrete Angebot belastbar?

Sind Leistungsumfang, Kosten, Rechte, Abnahme, Dokumentation, Betrieb und spätere Handlungsfreiheit ausreichend geregelt?

Gerade bei fünf- oder sechsstelligen Entwicklungsbudgets können kleine Unklarheiten erhebliche Auswirkungen haben. Was vor Vertragsabschluss noch verhandelbar ist, wird während eines laufenden Projekts schnell teuer.

Softwareprojekte nicht erst prüfen, wenn Probleme sichtbar werden

Viele Unternehmen holen externe Unterstützung erst hinzu, wenn Budget, Zeitplan oder Qualität bereits aus dem Ruder gelaufen sind.

Sinnvoller ist eine Prüfung an den entscheidenden Stellen des Projekts.

Vor der Beauftragung können Anbieter, Leistungsumfang und Vertragsbedingungen bewertet werden. Während der Entwicklung kann anschließend geprüft werden, ob gemeldeter Fortschritt, Codequalität, Tests und Budgetentwicklung tatsächlich zum Projektstand passen.

AVERVO bietet dafür eine spezialisierte Prüfung von Softwareprojekten. Sie richtet sich an Unternehmen, die individuelle Anwendungen, interne Systeme, Apps oder andere Eigenentwicklungen unabhängig bewerten lassen möchten.

Denn bei Individualsoftware entscheidet nicht allein, ob am Ende eine Anwendung funktioniert. Entscheidend ist, ob das Unternehmen ein technisch tragfähiges, wirtschaftlich vertretbares und langfristig beherrschbares System erhält.

Häufige Fragen