Was kostet App-Entwicklung? Warum Angebote um ein Vielfaches abweichen und wie Sie sie vergleichen

Ein Modellfall: Ein Unternehmen möchte eine individuelle App entwickeln lassen, schickt seine Anforderungen an drei Anbieter, und das teuerste der drei Angebote beträgt ein Vielfaches des günstigsten. Der erste Verdacht liegt nahe: Jemand verlangt überhöhte Preise.

Der Unterschied kann jedoch darin liegen, was ein Anbieter in sein Angebot eingepreist, was er weggelassen und welches Risiko er Ihnen überlassen hat.

Ob sich ein eigenes System lohnt, erläutern wir im Artikel Ein gutes internes System kann sich schneller bezahlt machen als ein neuer Mitarbeiter. Hier setzen wir einen Schritt später an: Die Angebote liegen auf dem Tisch, und die Frage lautet, was die App-Entwicklung kostet, wenn sich jeder Anbieter die App anders vorstellt.

Ein vielfach höherer Preis ist nicht automatisch überteuert

Bente Anda, Dag Sjøberg und Audris Mockus beschrieben in einer Studie aus dem Jahr 2009 eine Ausschreibung, in der das Simula Research Laboratory einen Anbieter für ein webbasiertes System suchte. Von 81 angefragten Unternehmen in Norwegen reichten 35 ein Festpreisangebot ein, alle auf Grundlage derselben 11-seitigen Spezifikation. Die Beträge ohne Mehrwertsteuer lagen zwischen 2.630 und 69.940 Euro, ein Unterschied um etwa das 26,6-Fache. Aufschlussreich ist das Verhältnis, nicht die heute bereits historischen Beträge.

Die Unternehmen hielten die Spezifikation dabei für gut ausgearbeitet. Dennoch unterschieden sich die Angebote auch im Umfang von Analyse und Entwurf, von gar keinem bis hin zu Screens, Architektur und Datenmodellen. Einen Zusammenhang zwischen Preis und geplantem Vorgehen fanden die Autoren nicht, und aus den Angeboten ließ sich ihnen zufolge nur begrenzt ablesen, wie ein Unternehmen arbeitet und welche Qualität es liefern will. Der Betrag allein verrät also nicht, was Sie dafür bekommen.

In einer Vorphase desselben Verfahrens gaben 17 dieser Unternehmen eine unverbindliche Schätzung ab, allein auf Grundlage einer einseitigen Bedarfsbeschreibung. Die höchste lag laut Magne Jørgensen und Gunnar J. Carelius etwa zehnmal so hoch wie die niedrigste, unter anderem wegen Unterschieden in den vorgeschlagenen Lösungen und in der Produktivität. Die Autoren weisen darauf hin, dass der Angebotspreis bei einer vagen Spezifikation das Projekt nicht nur widerspiegelt, sondern auch definiert.

Woraus sich der Preis zusammensetzt

Wenn die Anforderungen dazu nichts sagen, trifft der Anbieter diese Entscheidungen für Sie:

• Funktionsumfang. Was die App können wird und was nicht. Der Satz „Der Nutzer generiert einen Report“ kann einen Export als Tabelle ebenso bedeuten wie ein Analysemodul.
• Integrationen. Anbindungen etwa an die Buchhaltung. Ihr Aufwand hängt von Schnittstellen ab, die der Anbieter unter Umständen nicht kennt.
• Design und UX. Die UX, also das Nutzungserlebnis, beeinflusst, ob Menschen die App annehmen, wie wir im Artikel Das teuerste System ist das, das Ihre Mitarbeiter nicht nutzen beschreiben. Eine fertige Vorlage ist günstiger als ein Entwurf, der mit Nutzern getestet wurde.
• Datenmodell. Die Struktur der Daten und ihrer Beziehungen. Alles andere baut darauf auf, deshalb lassen sich Fehler darin nur schwer beheben.
• Sicherheit und Berechtigungen. Eine einzige Rolle für alle ist günstig, Zugriffsrechte je nach Position müssen dagegen konzipiert und getestet werden.
• Tests. Automatisierte Tests prüfen nach jeder Änderung, ob die bestehenden Funktionen weiterhin funktionieren. Ohne sie testen Ihre Mitarbeiter.
• Projektmanagement. Koordination und Änderungsmanagement. Prüfen Sie, ob es im Preis enthalten ist oder ob jemand aus Ihrem Haus diese Aufgabe übernehmen muss.

Unterschiede verbergen sich auch in den nicht-funktionalen Anforderungen. Sie beschreiben nicht, was ein System tut, sondern wie gut es das tut: Geschwindigkeit, Zuverlässigkeit oder Wartbarkeit, also wie leicht es sich ändern lässt. In der norwegischen Studie waren sie weniger detailliert beschrieben als die funktionalen, und die Autoren empfehlen, sie bereits in den Anforderungen festzulegen, vor allem die Wartbarkeit. Helfen kann das Qualitätsmodell der Norm ISO/IEC 25010:2023, das auch Auftraggeber bei der Spezifikation nutzen können.

Was im Angebot fehlen kann

Prüfen Sie diese Positionen bei jedem Anbieter. Wurden sie in den Anforderungen nicht erwähnt, hat sie womöglich der eine eingepreist und der andere nicht.

• Administration. Verwaltung von Benutzern, Stammdaten und Inhalten. Ohne sie erledigt jede kleine Änderung ein Entwickler, und zwar gegen Rechnung.
• Datenmigration. Übernahme und Bereinigung der Daten aus dem Altsystem oder aus Tabellen.
• Mehrsprachigkeit. Ist der Code nicht von Anfang an darauf ausgelegt, kann die Nachrüstung einen großen Teil der App betreffen.
• Barrierefreiheit. Nutzbarkeit auch für Menschen mit Behinderungen. Wer sie nachträglich umsetzt, muss fertige Screens überarbeiten.
• Support nach dem Go-live. Fehlerbehebungen, Sicherheitsupdates und Hilfe für Nutzer. Fehlt er, wird das erste Problem im Betrieb zu einem neuen Auftrag.

Die Kosten über Jahre der Nutzung analysieren wir im Artikel Sieben SaaS-Tools oder ein einziges System? Für die Prüfung eines Angebots genügt daraus eine Erkenntnis: Code ohne Tests und Dokumentation ist günstiger in der Lieferung, aber teurer in der Änderung, weil ein Entwickler bei jeder Anpassung zuerst herausfinden muss, was durch die Änderung nicht mehr funktionieren würde.

Wer das Risiko trägt: Festpreis, Time and Material, Hybridmodell

Festpreis bedeutet, dass der Anbieter das Risiko einer Kostenüberschreitung trägt und es deshalb einpreist: Je vager die Anforderungen, desto größer der Risikopuffer oder desto enger die Auslegung des Leistungsumfangs. Die US-Beschaffungsvorschrift für Bundesaufträge, die Federal Acquisition Regulation, hält fest, dass ein Festpreisvertrag dem Auftragnehmer das größtmögliche Risiko auferlegt und dass über den Vertragstyp zusammen mit dem Preis verhandelt werden soll. Das ist US-Recht, die Logik lässt sich unserer Ansicht nach jedoch übertragen.

Time and Material bedeutet, dass Sie die geleisteten Stunden zu vereinbarten Sätzen bezahlen und das Risiko der Unsicherheit selbst tragen. Dieselbe Vorschrift lässt dieses Modell nur zu, wenn sich Umfang oder Dauer der Arbeiten nicht im Voraus hinreichend genau schätzen lassen. Da es dem Anbieter keinen Anreiz zur Kostenkontrolle bietet, verlangt die Vorschrift eine Überwachung durch den Auftraggeber. Außerdem verlangt sie eine Preisobergrenze, deren Überschreitung auf eigenes Risiko des Anbieters geht.

Ein Hybridmodell mit festem erstem Meilenstein sieht einen Festpreis für die erste Phase mit klar definiertem Ergebnis vor, etwa für eine Analyse oder einen Prototyp. Über den Rest wird erst entschieden, wenn der Umfang beschrieben ist. Der Anbieter trägt das Risiko einer kleinen Phase, und Sie entscheiden über den Großteil des Budgets mit besseren Informationen. Die erste Phase kostet allerdings Geld und Zeit, und ihr Ergebnis muss auch ein anderer Anbieter verwenden können, sonst kaufen Sie sich die Abhängigkeit nur eine Phase früher ein.

Unklare Anforderungen bezahlen Sie während der Entwicklung

Ein Change Request ist ein formaler Antrag auf Änderung des vereinbarten Leistungsumfangs, mit eigenem Preis und Auswirkungen auf den Termin. Bei unpräzisen Anforderungen wird die Ausnahme zur Regel, weil sich fehlende Teile erst während der Entwicklung zeigen.

Jørgensen und Carelius führen an, dass Kostenüberschreitungen auf Anbieterseite häufig auf Anforderungsänderungen zurückgehen, die sich dem Kunden nicht in Rechnung stellen lassen. Wer mit einem niedrigen Preis den Zuschlag erhalten hat, hat deshalb unserer Ansicht nach ein starkes Motiv, jede Abweichung als Änderung abzurechnen. Legt der Vertrag Verrechnungssatz, Schätzmethode und Freigabe von Änderungen nicht vorab fest, verhandeln Sie über deren Preis zu einem Zeitpunkt, an dem Sie den Anbieter nicht mehr ohne Weiteres wechseln können.

Unklare Anforderungen bezahlen Sie allerdings nicht nur über Rechnungen. Das Framework Cost of Friction, das wir in diesem Blog verwenden, berechnet die Reibungskosten als Zeit × Häufigkeit × Anzahl der Personen × Kosten. Modellrechnung mit hypothetischen Werten: 30 unklare Punkte in den Anforderungen, von denen jeder zwei Stunden Besprechung mit drei Ihrer Mitarbeiter beansprucht, ergeben 2 × 30 × 3 = 180 Stunden interne Arbeit. Niemand stellt sie Ihnen in Rechnung, und doch bezahlen Sie dafür. Setzen Sie Ihre eigenen Zahlen und Ihre internen Stundenkosten ein.

Rechte am Code und die Möglichkeit, den Anbieter zu wechseln

Vendor-Lock-in bezeichnet den Zustand, in dem Sie den Anbieter nicht ohne Weiteres wechseln können, weil nur er das System versteht. Die Europäische Kommission gab 2016 an, dass 42 % der untersuchten Organisationen Erfahrungen mit einem IKT-Lock-in eingeräumt hatten.

Nach § 91 Abs. 4 des slowakischen Urheberrechtsgesetzes Nr. 185/2015 Slg. in der ab dem 1. September 2026 geltenden Fassung gelten für ein Computerprogramm, das ganz oder teilweise im Auftrag erstellt wurde, die Bestimmungen über Werke im Arbeitsverhältnis, und der Auftraggeber gilt als Arbeitgeber. Sofern nichts anderes vereinbart ist, übt also der Auftraggeber die vermögensrechtlichen Befugnisse aus, insbesondere das Recht, das Werk zu nutzen, er kann ihre Ausübung einem Dritten übertragen, und der Urheber gilt auch als mit einer Änderung des Werkes einverstanden (§ 90 Abs. 4 bis 6). Das ist slowakisches Recht; andere Länder können das anders regeln. Unabhängig vom Land sollte der Vertrag daher ausdrücklich festhalten, wem der Code gehört.

Unter einem Auftragswerk versteht das Gesetz ein Werk, das auf Grundlage eines Werkvertrags geschaffen wurde, und entscheidend ist auch, was die Parteien vereinbart haben. Zudem regelt das Gesetz Rechte, nicht die Übergabe: Ohne den Quellcode in Ihrem eigenen Repository, ohne Zugänge und ohne Dokumentation nützt Ihnen das Recht, das Werk zu ändern, wenig.

Der Vertrag sollte auch bereits bestehende Bestandteile regeln, die der Anbieter mitbringt, etwa seine Plattform oder kostenpflichtige Komponenten, denn diese sind nicht in Ihrem Auftrag entstanden. Dies ist keine Rechtsberatung, lassen Sie den Vertrag von einem Rechtsanwalt prüfen.

So vergleichen Sie Angebote

Stellen Sie allen Anbietern dieselben Fragen und halten Sie die Antworten nebeneinander fest:

1. Was gehört zum Leistungsumfang, und was schließen Sie ausdrücklich aus?
2. Welche Annahmen haben Sie zu Integrationen, Daten und Rollen getroffen?
3. Wie gehen Sie mit Performance, Sicherheit und Wartbarkeit um, und was testen Sie?
4. Wie bepreisen und genehmigen Sie Änderungen am Leistungsumfang?
5. Was umfasst der Support nach dem Go-live, und was kostet das erste Betriebsjahr?
6. Welche Rechte am Code erhalten wir, wo wird er gespeichert, und wie läuft eine Übergabe an einen anderen Anbieter ab?

Die Autoren der norwegischen Studie empfehlen, dass Angebote Arbeitsweisen und Qualitätsansprüche ausdrücklich benennen, statt sie nur implizit im Festpreis zu verstecken. Als Warnsignale sehen wir:

• Festpreis ohne Rückfragen. Vage Anforderungen, die ohne klärende Rückfragen mit einem festen Betrag bepreist werden, können auf einer engen Auslegung des Leistungsumfangs beruhen oder auf einem Risikopuffer, von dem Sie nichts wissen.
• Fehlende Tests. Fehler finden dann erst Ihre Nutzer.
• Unklare Rechte und Zugänge. Es ist nicht geklärt, wo der Code gespeichert wird, oder die Zugänge sind an die Dauer der Zusammenarbeit gebunden.

Wann das günstigere Angebot die richtige Wahl ist

Vier Unternehmen aus der norwegischen Studie entwickelten das System schließlich unabhängig voneinander. Das günstigste von ihnen, für 8.750 Euro, überschritt den vereinbarten Termin um 93 % und wies eine geringe Zuverlässigkeit und Wartbarkeit auf. Das teuerste, für 56.000 Euro, überschritt ihn um 5 % und bot eine gute Benutzbarkeit und Wartbarkeit. Gemessen am Preis war es 6,4-mal so teuer, unter Einrechnung des Aufwands auf Auftraggeberseite nur noch 3,4-mal. Die Ergebnisse folgten nicht der Rangfolge der Preise, und das günstigere System konnte laut den Autoren die beste Wahl für einen Auftraggeber sein, der Verzögerungen toleriert, über ausreichend Fachkompetenz verfügt und an einige Qualitätsaspekte geringere Anforderungen stellt.

Das kann etwa ein internes Tool mit kurzer Lebensdauer sein oder die Validierung einer Idee.

In den Daten von Magne Jørgensen zu 785.325 überwiegend sehr kleinen Aufträgen auf einem globalen Outsourcing-Marktplatz senkte eine frühere Zusammenarbeit zwischen Kunde und Anbieter das Risiko des Scheiterns am stärksten, und zwar auf 17 % des Niveaus von Projekten ohne eine solche Zusammenarbeit. Kunden, die ein Angebot mit einem Preis mindestens auf Durchschnittsniveau wählten, hatten unter sonst gleichen Bedingungen ein Risiko von 85 % des Niveaus jener Kunden, die stärker auf einen niedrigen Preis achteten. Auf größere Projekte lässt sich das laut dem Autor nur mit Vorsicht übertragen. Am besten prüft man einen Anbieter seiner Ansicht nach mit einer realistischen Probe, etwa einem echten Projekt, und das kann eine kleine bezahlte erste Phase sein.

Eine Vorphase macht aus der Schätzung einen Plan

Steve McConnell beschreibt den Cone of Uncertainty, den Unsicherheitskegel, ein Modell dafür, wie die Genauigkeit von Schätzungen im Projektverlauf zunimmt. In der Phase des ersten Konzepts können selbst die Schätzungen erfahrener Schätzer um den Faktor vier in beide Richtungen danebenliegen, also mit einer Spannweite um das 16-Fache, und genauer geht es ihm zufolge nicht. Eine weitere Woche Schätzarbeit verengt den Kegel nicht, das tun nur Entscheidungen darüber, was das Produkt tun wird und was nicht, über die Anforderungen und über die Benutzeroberfläche.

Diese Entscheidungen liefert eine Analyse oder ein Prototyp. Die Anbieter kalkulieren dann zumindest denselben Leistungsumfang, auch wenn das keine ähnlichen Preise garantiert, wie die norwegische Studie gezeigt hat.

Die Unternehmen, die in dem erwähnten Verfahren zunächst auf Grundlage der einseitigen Beschreibung geschätzt hatten, boten später auf die detaillierte Spezifikation im Durchschnitt höhere Preise an als die übrigen. Jørgensen und Carelius empfehlen deshalb, keine Richtpreise auf Basis unvollständiger Informationen einzuholen, wenn die finalen Angebote auf vollständigeren beruhen können.

Eine bezahlte Analyse ist dabei keine Pflicht. Bei einer kleinen, klar abgegrenzten App kann es genügen, die Anforderungen mit eigenen Mitteln zu präzisieren. Eine Analyse kann auch zeigen, dass Sie gar keine Entwicklung brauchen, weil sich das Problem durch einen vereinfachten Prozess oder ein fertiges Tool lösen lässt. Auf die Frage nach den Kosten der App-Entwicklung gibt es deshalb keine ehrliche Antwort, bevor klar ist, welches Problem die App lösen soll.

Was Sie mitnehmen

• Ein Preisunterschied um ein Vielfaches muss nicht auf überhöhte Preise hindeuten. Dahinter können ein anderer Leistungsumfang, eine andere Lösung oder ein Risikopuffer stecken.
• Stellen Sie allen Anbietern dieselben Fragen und vergleichen Sie Leistungsumfang, Ausschlüsse und Annahmen, nicht nur die Endbeträge.
• Wenn sich die Anforderungen präzisieren lassen, holen Sie keine Richtpreise auf Basis einer vagen Beschreibung ein. Ist der Umfang unklar, beginnen Sie mit einer Vorphase zum Festpreis, deren Ergebnis auch ein anderer Anbieter nutzen kann.
• Regeln Sie vor der Unterzeichnung im Vertrag die Rechte am Code, die Zugänge, die Dokumentation und die vorhandenen Komponenten, und lassen Sie ihn von einem Rechtsanwalt prüfen.
• Das günstigere Angebot kann die richtige Wahl sein, wenn Sie Verzögerungen verkraften, geringere Qualitätsansprüche haben und die Lieferung fachlich überwachen können.