Die 9 teuersten Fehler beim Beauftragen von Individualsoftware

“Das günstigste Angebot ist halb so teuer wie die anderen beiden. Das nehmen wir.” Der Satz fällt öfter, als du denkst. Und er ist fast nie der Grund, warum ein Softwareprojekt am Ende weh tut.

Die teuersten Fehler beim Softwareentwickeln lassen stehen nämlich gar nicht im Angebot. Sie passieren vorher, in Gesprächen, in denen niemand über Geld redet. Wem gehört der Quellcode? Wer darf freigeben? Was passiert nach dem Launch? Wer diese Fragen überspringt, merkt das nicht am Tag der Unterschrift. Sondern anderthalb Jahre später.

Hand aufs Herz: Die meisten dieser Fehler sind keine Dummheit. Sie entstehen, weil niemand sie dir vorher gezeigt hat.

Warum die teuersten Fehler vor der ersten Zeile Code passieren

Über Scheiternsquoten von Softwareprojekten kursieren wilde Zahlen. Die bekannteste, wonach angeblich drei Viertel aller Projekte scheitern, hat keine saubere Primärquelle, und auch der viel zitierte Chaos Report der Standish Group gilt in der Forschung als methodisch angreifbar. Die Wissenschaftler Eveleens und Verhoef haben ihm schon 2010 vorgerechnet, dass seine Definition von “Erfolg” die Ergebnisse verzerrt. Lass uns also nicht über Quoten reden, sondern über Mechanismen.

Der Mechanismus ist simpel. Beim Beauftragen legst du Dinge fest, die später kaum noch verhandelbar sind: Rechte, Vertragstyp, Umfang, Zuständigkeiten. Code kannst du umschreiben. Einen Vertrag, den du unterschrieben hast, nicht. Deshalb sind die Fehler aus dieser Phase die teuersten, obwohl sie in dem Moment nichts kosten.

Die 9 teuersten Fehler beim Softwareentwickeln lassen

1. Du beschreibst eine Lösung statt eines Problems. “Wir brauchen ein Dashboard mit Ampelanzeige” ist eine Lösung. Was dahintersteckt, nämlich dass niemand sieht, welche Aufträge feststecken, ist das Problem. Wer die Lösung bestellt, bekommt exakt sie geliefert, inklusive der Denkfehler, die drinstecken. Beschreib stattdessen deinen Prozess und wo er hakt. Wie du daraus ein sauberes Lastenheft machst, haben wir im Beitrag zu Lastenheft und Pflichtenheft beschrieben.

2. Du prüfst nicht, ob Standardsoftware auch reichen würde. Individualsoftware ist nicht per se besser, sie ist per se teurer. Manchmal deckt ein Standardprodukt für ein paar hundert Euro im Monat 90 Prozent ab, und die fehlenden 10 Prozent sind ein Gewohnheitsproblem, kein Geschäftsproblem. Stell die Frage vor der Ausschreibung, nicht danach. Unser Make-or-Buy-Vergleich geht das strukturiert durch.

3. Du vergleichst Angebote über die Endsumme. Drei Angebote, drei Zahlen, eine Entscheidung. Das Problem: Die Zahlen beschreiben nicht dasselbe. Der Günstigste hat meistens den kleinsten Umfang angenommen, Tests knapper kalkuliert oder Schnittstellen als “Aufwand nach Aufwand” ausgeklammert. Vergleich stattdessen die Annahmen: Wie viele Tage? Welche Schnittstellen sind drin? Wer testet? Wer haftet, wenn es nicht läuft?

4. Du klärst die Nutzungsrechte nicht schriftlich. Der teuerste Punkt auf dieser Liste, und der am häufigsten übersehene. Ohne ausdrückliche Regelung greift im deutschen Urheberrecht die Zweckübertragungslehre: Der Entwickler räumt nur die Rechte ein, die der Vertragszweck zwingend erfordert. Laut IT-Recht Kanzlei bekommst du damit im Zweifel ein einfaches, nicht übertragbares Nutzungsrecht. Mehr nicht. Kein Anspruch auf den Quellcode, kein Recht, die Software umbauen zu lassen, keine Übertragbarkeit, wenn du den Betrieb mal verkaufst. Du hast die Entwicklung bezahlt und darfst die Software trotzdem nicht von jemand anderem weiterentwickeln lassen. Lass dir ausschließliche, übertragbare Nutzungsrechte inklusive Bearbeitungsrecht und Quellcode-Herausgabe schriftlich geben, vor der ersten Rechnung.

5. Du hältst einen Stundensatz-Vertrag für eine Erfolgsgarantie. Werkvertrag heißt: geschuldet ist ein Ergebnis, es gibt eine Abnahme. Dienstvertrag heißt: geschuldet ist Tätigkeit, das Projektrisiko liegt bei dir. Das OLG Frankfurt hat im Dezember 2024 einen Vertrag über die Entwicklung von Software-Schnittstellen als Dienstvertrag eingestuft. Nicht wegen einer Kleinigkeit, sondern wegen einer Kette von Indizien: Abgerechnet wurde nach Stunden, im Vertrag stand mehrfach das Wort Dienstleistungen, und beide Seiten konnten mit einer Frist von 28 Tagen kündigen. Ergebnis: keine Abnahme nötig, gezahlt wird für Zeit, auch ohne fertiges Produkt. Wenn du ein Ergebnis kaufen willst, muss das Wort Werkvertrag im Vertrag stehen, samt Abnahmekriterien.

6. Du planst kein Wartungsbudget. Software ist kein Möbelstück. Sie braucht Sicherheitsupdates, Anpassungen an neue Schnittstellen, Bugfixes. Aus unserer Projekterfahrung solltest du 15 bis 25 Prozent der Entwicklungskosten pro Jahr einplanen, und die Spanne ist ehrlich gemeint: Wie viel Weiterentwicklung drinsteckt, entscheidet, wo du landest. Bei 60.000 € Entwicklung sind das 9.000 bis 15.000 € jährlich. Wer das nicht einplant, hat kein Wartungsproblem. Er hat ein Budgetproblem.

7. Du benennst keinen Entscheider. Freigaben zu Design, Texten, Zugängen, Prioritäten. Jeder Tag, an dem eine Freigabe im Postfach liegt, ist ein Tag Stillstand oder Kontextwechsel im Team. Acht Sprints, jeweils drei Tage Verzug bei der Freigabe, macht überschlagen fast vier Wochen extra. Benenn eine Person, die innerhalb von ein bis zwei Tagen ja sagen darf, ohne Komitee.

8. Du willst alles in Version 1. Jede Idee, die während des Baus dazukommt, verlängert und verteuert. Und die bittere Pointe: Ein Teil der Funktionen, für die du zahlst, wird später kaum benutzt, weil vorher niemand wusste, was im Alltag wirklich zählt. Frier den Umfang für Version 1 ein und führ eine Liste für Version 2. Das ist kein Verzicht, das ist Reihenfolge.

9. Du klärst nicht, wer die Software in drei Jahren betreut. Ein Freelancer baut günstig und ist irgendwann weg. Dann steht undokumentierter Code da, den niemand anfassen will. Auf einen eigenen Entwickler auszuweichen, dauert: Laut Bitkom fehlen in der deutschen Wirtschaft rund 109.000 IT-Fachkräfte, eine offene IT-Stelle bleibt im Schnitt 7,7 Monate unbesetzt. Kläre vor der Beauftragung, wer Wartung übernimmt, wie dokumentiert wird und was passiert, wenn ihr euch trennt.

Was diese Liste nicht leistet

Diese neun Punkte sind kein Schutzschild. Du kannst alles davon richtig machen und trotzdem ein Projekt haben, das aus dem Ruder läuft, weil sich dein Markt dreht oder eine Schnittstelle beim Fremdanbieter kaputtgeht. Software bleibt ein Vorhaben mit Unsicherheit, kein Katalogkauf.

Und noch etwas: Die Punkte zu Nutzungsrechten und Vertragstyp sind Praxiserfahrung, keine Rechtsberatung. Sie ersetzen keinen Anwalt. Wenn es um größere Summen geht, lass den Vertrag von jemandem prüfen, der dafür haftet.

Und ehrlich gesagt: Manche dieser Fehler kosten dich wenig, wenn dein Projekt klein ist. Bei einem internen Tool für 8.000 € ist der Streit um Bearbeitungsrechte akademisch. Ab der Größenordnung, in der die Software Teil deines Tagesgeschäfts wird, ist er es nicht mehr. Genau da entscheidet sich, ob du in fünf Jahren noch handlungsfähig bist oder von einem Anbieter abhängst, den du nicht mehr magst.

Was du jetzt tun kannst

Wenn du nur drei Dinge aus dieser Liste mitnimmst, dann diese: Nutzungsrechte schriftlich, Vertragstyp bewusst wählen, Wartungsbudget von Anfang an einplanen. Diese drei kosten dich beim Beauftragen keinen Cent extra und sparen dir später fünfstellige Beträge.

Der Rest ist Handwerk und Ehrlichkeit auf beiden Seiten. Ein guter Anbieter erklärt dir diese Punkte von selbst, bevor du fragst. Wer bei “Wem gehört der Code?” ausweicht, hat dir die Antwort schon gegeben.

Willst du wissen, wo bei deinem Vorhaben die teuren Punkte liegen? Schau dir an, wie wir Software entwickeln, oder nimm dir eine Fokus-Session. Eine Stunde, in der wir gemeinsam auf deine Anforderungen und deinen Vertragsentwurf schauen. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung.