Individuelle Softwareentwicklung: Wann sie sich lohnt und worauf Sie achten

Für wen sich Individualsoftware lohnt

Individuelle Softwareentwicklung heißt: Eine Anwendung wird nach Ihren Anforderungen gebaut, statt ein fertiges Produkt zu konfigurieren. Das ist selten die günstigste Lösung, aber oft die passendste, wenn der betroffene Prozess Ihr Geschäft ausmacht.

Typische Fälle (illustrativ, keine realen Projekte):

• Ein Handelsunternehmen kalkuliert Angebote nach eigenen Regeln, die kein Warenwirtschaftssystem abbildet.
• Ein Verband verwaltet Mitglieder, Veranstaltungen und Gremien in einer über Jahre gewachsenen Tabellenlandschaft.
• Ein Fertigungsbetrieb braucht eine Auftragssteuerung, die Maschinendaten, Lager und Kundentermine zusammenführt.

Dagegen spricht: Wenn ein Standardprodukt Ihre wesentlichen Anforderungen ohne Umbau erfüllt und der Rest verzichtbar ist, wird eine Eigenentwicklung selten wirtschaftlich. Die Abwägung finden Sie ausführlich im Ratgeber Individualsoftware oder Standardsoftware.

Alternativen, bevor Sie beauftragen

Was Sie als Auftraggeber mitbringen müssen

Ein Dienstleister kann Software bauen, aber nicht für Sie entscheiden, was Ihr Prozess leisten soll. Planen Sie deshalb Zeit ein für:

• einen fachlichen Ansprechpartner, der Entscheidungen treffen darf und regelmäßig verfügbar ist,
• eine Beschreibung des heutigen Ablaufs, einschließlich Ausnahmen, die in der Praxis ständig vorkommen,
• Beispieldaten und Zugang zu Systemen, mit denen die Software sprechen muss,
• eine Einschätzung, wer die Software nutzt und welche Rechte jede Rolle braucht.

Mit dem Werkzeug Projekt vorbereiten können Sie diese Angaben strukturiert zusammentragen, bevor Sie Angebote einholen.

Ablauf in Phasen

Der Ablauf unterscheidet sich je nach Anbieter, folgt aber meist diesem Muster. Die Dauer hängt von Umfang, Entscheidungswegen und Ihrer Verfügbarkeit ab; verlässliche Zeitangaben gibt es erst nach der Discovery.

Das Muster zeigt auch, wo Ihre Zeit gebraucht wird: Verzögerungen entstehen häufig nicht durch die Entwicklung, sondern durch ausstehende Entscheidungen und Testrückmeldungen auf Auftraggeberseite.

Discovery und Lastenheft

In der Discovery klären Auftraggeber und Dienstleister Ziele, Nutzer, Abläufe, Risiken und Schnittstellen. Ergebnis ist idealerweise ein Lastenheft oder eine priorisierte Anforderungsliste. Was darin steht, bestimmt später, worüber sich beide Seiten streiten können. Wie es aufgebaut ist, erklärt der Ratgeber Lastenheft für Software.

Typisch ist, die Discovery als eigenen, kleinen Auftrag zu vergeben. So können Sie die Ergebnisse auch Dritten für Vergleichsangebote geben.

MVP und Iterationen

Ein MVP (Minimum Viable Product) ist die kleinste Version, die einen echten Arbeitsablauf abdeckt. Danach folgen Iterationen: Funktionen werden in Abschnitten gebaut, gezeigt und korrigiert. Das reduziert das Risiko, am Ende etwas Fertiges zu erhalten, das niemand braucht. Fragen Sie im Angebot nach, wie oft Ergebnisse gezeigt werden und wer Prioritäten entscheidet.

Test und Abnahme

Die Abnahme ist der Moment, in dem Sie das Werk als vertragsgemäß anerkennen. Sie sollte an vorab vereinbarten Kriterien hängen, zum Beispiel an einer Liste von Abläufen, die fehlerfrei durchlaufen werden müssen. Eine Abnahme ohne Kriterien führt oft zu Diskussionen über „fertig“.

Vertragsart: Werkvertrag oder Dienstvertrag

Beim Werkvertrag schuldet der Unternehmer ein vereinbartes Ergebnis, der Besteller die Vergütung (§ 631 BGB). Beim Dienstvertrag schuldet der Dienstleister die versprochenen Dienste, aber keinen bestimmten Erfolg (§ 611 BGB). Für Software heißt das in der Praxis:

• Werkvertrag passt, wenn der Leistungsumfang genau beschrieben werden kann. Er bietet Klarheit über das Ergebnis, aber wenig Flexibilität bei Änderungen.
• Dienstvertrag / agile Zusammenarbeit passt, wenn sich Anforderungen im Verlauf klären. Sie steuern über Budgetrahmen, Prioritäten und regelmäßige Ergebnisse, tragen aber mehr Verantwortung für das Ergebnis: Ziele, Zwischenergebnisse und Abbruchkriterien müssen Sie selbst aktiv steuern.

Häufig werden beide kombiniert: Discovery als Dienstleistung, Umsetzung abschnittsweise mit klaren Teilabnahmen. Welche Konstruktion für Sie passt, sollte ein Rechtsanwalt prüfen. Dieser Text ist eine allgemeine Information und keine Rechtsberatung.

Was im Vertrag stehen sollte

Unabhängig von der Vertragsart lohnt sich ein Blick auf diese Punkte, bevor Sie unterschreiben. Lassen Sie den Vertrag juristisch prüfen; die Liste ersetzt keine Rechtsberatung.

• Nutzungsrechte: Umfang (ausschließlich oder einfach), Dauer, Gebiet, Recht zur Bearbeitung und Weitergabe
• Quellcode-Übergabe: Zeitpunkt (bei Abnahme, nicht erst auf Nachfrage), Form und Repository
• Dokumentation: Umfang und Aktualität, Architektur, Datenmodell, Schnittstellen, Betriebsanleitung
• Abnahmekriterien: Prüfablauf, Testfälle, Umgang mit Mängeln und Fristen für Nachbesserung
• Gewährleistung: Dauer, Umfang und Ablauf der Fehlerbehebung nach der Abnahme
• Wartung und Service-Level (SLA): Reaktions- und Behebungszeiten, Servicezeiten, Preise
• Datenschutz und AVV: Auftragsverarbeitungsvertrag, Unterauftragnehmer, Speicherort der Daten
• Exit: Zusammenarbeit bei Anbieterwechsel, Datenexport in offenen Formaten, Fristen und Kosten

Quellcode und Nutzungsrechte

Computerprogramme sind urheberrechtlich geschützt, sofern sie eine eigene geistige Schöpfung darstellen, und zwar in jeder Ausdrucksform (§ 69a UrhG). Die Ideen und Grundsätze dahinter sind nicht geschützt. Wer ein Programm rechtmäßig nutzt, darf es nach § 69d UrhG unter bestimmten Bedingungen vervielfältigen und anpassen, soweit das für die bestimmungsgemäße Nutzung nötig ist, es sei denn, der Vertrag sieht etwas anderes vor.

Praktisch bedeutet das: Ohne ausdrückliche Regelung bleibt unklar, ob Sie die Software ändern, durch einen anderen Dienstleister weiterentwickeln lassen oder in anderen Konzerngesellschaften einsetzen dürfen. Klären Sie im Vertrag:

• Umfang der Rechte: ausschließlich oder einfach, zeitlich und räumlich, für welche Nutzungsarten,
• Recht zur Bearbeitung und Weitergabe an Dritte,
• Umgang mit Open-Source-Komponenten und deren Lizenzen,
• Rechte an wiederverwendeten Bausteinen des Dienstleisters.

Das ist eine allgemeine Information, keine Rechtsberatung.

Was Sie als Lieferung verlangen sollten

• Quellcode in einem Repository, das Sie kontrollieren
• Build- und Deployment-Anleitung, mit der ein Dritter die Software neu bauen kann
• Technische und fachliche Dokumentation (Architektur, Datenmodell, Schnittstellen)
• Automatisierte Tests oder zumindest dokumentierte Testfälle
• Zugangsdaten und Konten (Hosting, Domain, Schnittstellen) auf Ihren Namen
• Liste aller Fremdkomponenten mit Lizenz
• Einweisung Ihrer Mitarbeitenden

Wartung und Betrieb nach dem Go-live

Software ist mit der Abnahme nicht fertig. Sie braucht Hosting, Sicherheitsupdates, Datensicherung und Anpassungen an neue Anforderungen. Typisch ist, dass nach dem Start Rückmeldungen aus dem Alltag eine weitere Runde Änderungen auslösen; kalkulieren Sie dafür ein Budget ein, statt es als Ausnahme zu behandeln.

Man unterscheidet üblicherweise drei Arten von Aufwand:

• Fehlerbehebung: Korrektur von Abweichungen zum vereinbarten Verhalten, in der Gewährleistung meist ohne zusätzliche Vergütung, danach nach Vereinbarung.
• Pflege: Aktualisierungen von Frameworks, Bibliotheken, Betriebssystemen und Zertifikaten, damit die Software sicher und lauffähig bleibt.
• Weiterentwicklung: neue Funktionen und geänderte Abläufe, meist als eigene Aufträge.

Ob ein Dienstleister aus Heidelberg oder aus einer anderen Region der Rhein-Neckar-Gegend beauftragt wird, ändert daran nichts: Entscheidend ist, dass Zuständigkeiten, Reaktionszeiten und Vertretung vertraglich festgelegt sind. Klären Sie vor Vertragsabschluss:

• Wo läuft die Anwendung, und auf wessen Konto? Bevorzugen Sie Verträge, die auf Ihren Namen laufen.
• Wer spielt Updates für Frameworks und Abhängigkeiten ein, in welchem Rhythmus?
• Welche Reaktionszeiten gelten bei Störungen, und was kostet der Bereitschaftsbetrieb?
• Wer darf Änderungen vornehmen, wenn der ursprüngliche Dienstleister nicht mehr zur Verfügung steht?

Wartung wird häufig als Pauschale oder Stundenkontingent vereinbart. Fragen Sie nach, was darin enthalten ist und was gesondert berechnet wird.

Kosten und Zeitrahmen: Treiber statt Pauschalen

Seriöse Zahlen ohne Kenntnis Ihres Falls gibt es nicht. Typische Kostentreiber sind:

• Zahl der Rollen, Rechte und Sonderfälle,
• Zahl und Qualität der Schnittstellen zu Altsystemen,
• Datenübernahme und Datenqualität,
• Anforderungen an Sicherheit, Revisionssicherheit und Barrierefreiheit,
• Reife der Anforderungen: je unklarer, desto größer der Puffer,
• Verfügbarkeit Ihrer Fachleute für Rückfragen und Tests.

Eine Einordnung finden Sie im Ratgeber Was kostet Individualsoftware.

Warnzeichen im Angebot

• Leistungsbeschreibung in wenigen Sätzen, aber mit Festpreis.
• Keine Abnahmekriterien, keine Aussage zu Tests.
• Keine Regelung zu Quellcode, Nutzungsrechten oder Dokumentation.
• Hosting und Domains laufen ausschließlich auf den Namen des Anbieters.
• Kein Ansprechpartner für den Betrieb nach der Abnahme.
• Druck, schnell zu unterschreiben, oder Rabatte nur bei sofortiger Zusage.
• Verwendung eines proprietären Frameworks, das nur der Anbieter pflegen kann, ohne Ausstiegsregelung.

Weitere Kriterien für den Vergleich bietet der Ratgeber Softwaredienstleister auswählen.

Nächster Schritt

Halten Sie vor dem ersten Gespräch fest, welchen Ablauf die Software unterstützen soll, wer sie nutzt und welche Systeme angebunden werden müssen. Das Werkzeug Projekt vorbereiten erzeugt daraus eine Kurzbeschreibung zum Kopieren. Den Aufbau eines belastbaren Anforderungsdokuments erklärt der Ratgeber Lastenheft für Software.