Warum ein Senior-Entwicklerteam weniger kostet als billige Software

Ein Senior-Entwicklerteam kostet mehr pro Tag und weniger pro funktionierendem Feature. Billige Software bezahlen Sie später: mit Nacharbeit, mit technischen Schulden, die jede Änderung verlangsamen, mit Ausfällen und Sicherheitsvorfällen und mit der Abhängigkeit von dem, der sie geschrieben hat. Die Forschung des DORA-Programms von Google zeigt, dass die besten Teams zugleich schneller und zuverlässiger ausliefern; Sie müssen also nicht Tempo gegen Qualität tauschen. Die praktische Frage ist, wie Sie einen erfahrenen Partner vor der Unterschrift von einem billigen unterscheiden. Genau dafür enthält dieser Leitfaden eine Checkliste.

Er richtet sich an Gründerinnen und Gründer, Geschäftsführungen und IT-Leitungen, die Software in Auftrag geben wollen oder deren bestehende Software langsam und teuer zu ändern geworden ist.

#Was billige Software wirklich kostet

Der Tagessatz ist die sichtbarste Zahl eines Softwareprojekts und die am wenigsten aussagekräftige. Bezahlt werden funktionierende Features über die Lebensdauer des Produkts, und diese Summe hängt weit stärker von der Qualität ab als vom Preis eines Tages. Die Kosten billiger Software kommen nur später.

Nacharbeit und technische Schulden

Martin Fowler beschreibt technische Schulden als eine von Ward Cunningham geprägte Metapher für Mängel der inneren Qualität, die ein System schwerer änderbar machen: Der Mehraufwand für jedes neue Feature sind die Zinsen auf diese Schulden. Sein Technical-Debt-Quadrant unterscheidet umsichtige Schulden, die ein Team bewusst eingeht, um ein Release zu erreichen, und danach zurückzahlt, von leichtsinnigen Schulden: Das Team spart an der Sauberkeit, weil es glaubt, sie sich nicht leisten zu können, oder weil es es nicht besser weiß. Billige Teams produzieren meist die leichtsinnige Sorte.

Die Zinsen lassen sich messen. In einer Studie über 39 proprietäre Produktiv-Codebasen fanden Adam Tornhill und Markus Borg heraus, dass Code niedriger Qualität 15-mal mehr Fehler enthielt als Code hoher Qualität und dass die Behebung von Problemen darin im Schnitt 124 % mehr Entwicklungszeit kostete. Fowler argumentiert in Is high quality software worth the cost?, dass der übliche Zielkonflikt bei innerer Qualität umgekehrt verläuft: Entwickler merken schon nach wenigen Wochen, dass schlechter Code sie ausbremst.

Ausfälle und fehlgeschlagene Releases

Software, die vor dem Release nicht getestet wird, testen Ihre Kunden. Jedes fehlgeschlagene Release kostet doppelt: einmal für den Vorfall und noch einmal für die Nacharbeit. Der CISQ-Bericht von 2022 bezifferte die Kosten schlechter Softwarequalität in den USA auf mindestens 2,41 Billionen US-Dollar, die angehäuften technischen Schulden auf rund 1,52 Billionen US-Dollar. Das sind Schätzungen für eine ganze Volkswirtschaft, keine Prognose für Ihr Projekt.

Sicherheitsvorfälle

Sicherheitslücken sind Qualitätsmängel, die jemand ausnutzt. Der Cost of a Data Breach Report 2026 von IBM beziffert die durchschnittlichen Kosten eines Datenlecks weltweit auf 4,99 Millionen US-Dollar. Viele Schwachstellen sind banal: fehlende Berechtigungsprüfungen, falsch konfigurierte Dienste und veraltete Abhängigkeiten, also genau die Arbeit, die billige Teams auslassen.

Abhängigkeit von dem, der den Code geschrieben hat

Die leiseste Kostenart ist der Lock-in. Wenn nur der ursprüngliche Entwickler den Code versteht, wenn Repository, Cloud-Konto oder App-Store-Eintrag auf seinen Namen laufen oder wenn nichts dokumentiert ist, können Sie den Dienstleister nicht wechseln, ohne neu anzufangen. Für Cloud-Dienste verpflichtet der EU Data Act die Anbieter seit dem 12. September 2025, einen Wechsel zu ermöglichen, und ab dem 12. Januar 2027 entfallen Wechselentgelte ganz. Das Wissen im Kopf eines Freelancers oder die Konten auf dem Namen einer Agentur gibt Ihnen aber keine Verordnung zurück. Das regeln Ihr Vertrag und Ihre Übergabe.

#Was die Forschung über Lieferperformance sagt

Die meistzitierte Forschung zur Softwareauslieferung stammt von DORA, einem Forschungsprogramm bei Google, das jedes Jahr Tausende IT-Fachleute befragt. Sie gibt Auftraggebern messbare Fragen an die Hand statt Adjektive.

Die vier Schlüsselmetriken, inzwischen fünf

DORA begann mit vier Schlüsselmetriken: zwei für den Durchsatz (wie schnell Änderungen in Produktion gelangen) und zwei für die Stabilität (wie oft dabei etwas schiefgeht und wie schnell Sie sich erholen). Der aktuelle Metrik-Leitfaden ergänzt eine fünfte, die Rework-Rate:

• Change Lead Time: die Zeit vom Commit einer Änderung in der Versionsverwaltung bis zu ihrem Betrieb in Produktion.
• Deployment-Frequenz: wie oft Änderungen in Produktion ausgeliefert werden.
• Change Fail Rate: der Anteil der Deployments, die danach einen dringenden Eingriff brauchen, etwa einen Rollback oder einen Hotfix.
• Wiederherstellungszeit nach fehlgeschlagenem Deployment: wie lange es dauert, sich von einem fehlgeschlagenen Deployment zu erholen.
• Deployment-Rework-Rate: der Anteil ungeplanter Deployments, die durch einen Vorfall in Produktion ausgelöst werden.

Der zentrale Befund lautet: Tempo und Stabilität sind kein Zielkonflikt. Bei den meisten Teams bewegen sich die Metriken gemeinsam, und die besten Teams schneiden bei allen gut ab, weil dieselben Praktiken beides antreiben: kleine Änderungen, automatisierte Tests, automatisierte Deployments und schnelles Feedback. Ein Partner, der Ihnen sagt, Qualität verlangsame das Projekt, hat die Daten gegen sich.

KI macht das Team wichtiger, nicht unwichtiger

KI-Coding-Assistenten sind heute Standard, und sie verändern die Rechnung billiger Teams. Der DORA-Bericht 2024 schätzte, dass mit zunehmender KI-Nutzung der Lieferdurchsatz um 1,5 % und die Lieferstabilität um 7,2 % sanken. Der Bericht 2025 mit knapp 5.000 Befragten fand einen positiven Zusammenhang mit dem Durchsatz, aber weiterhin einen negativen mit der Stabilität, und fasste es in einem Satz zusammen: KI repariert kein Team, sie verstärkt, was schon da ist. Generierter Code ist billig. Zu beurteilen, ob er korrekt, sicher und wartbar ist, ist die Arbeit erfahrener Entwickler.

#Sicherheitsgrundlagen, die ein gutes Team unaufgefordert erledigt

Die OWASP Top 10 sind die maßgebliche Liste der kritischsten Sicherheitsrisiken in Webanwendungen. Die Ausgabe 2025 nennt fehlerhafte Zugriffskontrolle an erster Stelle, gefolgt von Sicherheitsfehlkonfiguration und Schwachstellen in der Software-Lieferkette. Um diese Risiken zu vermeiden, braucht es keinen Sicherheitsspezialisten, sondern Entwickler, die die Schutzmaßnahmen von Anfang an einbauen:

• Zugriffskontrolle auf dem Server. Jede Anfrage prüft, wer der Nutzer ist und was er sehen darf, statt Schaltflächen in der Oberfläche auszublenden.
• Konfiguration als Code. Umgebungen entstehen aus versionierter Konfiguration, mit Secrets in einem Secret Store und ohne Standardpasswörter.
• Abhängigkeiten unter Kontrolle. Bibliotheken sind fest versioniert, werden gescannt und aktualisiert, und neue Pakete werden vor der Installation geprüft.
• Umgang mit Eingaben. Datenbankabfragen sind parametrisiert, Eingaben werden an jeder Grenze validiert.
• Logging und Alarmierung. Sicherheitsrelevante Ereignisse werden protokolliert, und bei Auffälligkeiten wird jemand alarmiert.

In der EU ist das auch eine rechtliche Pflicht. Art. 32 DSGVO verlangt eine dem Risiko angemessene Sicherheit, einschließlich eines Verfahrens zur regelmäßigen Überprüfung und Bewertung, und Art. 28 verlangt einen Auftragsverarbeitungsvertrag (AVV) mit jedem Auftragsverarbeiter, also auch mit Ihrem Entwicklungspartner, wenn er mit personenbezogenen Daten arbeitet. Ein erfahrener Partner spricht beides an, bevor Sie es tun.

#Was „senior“ wirklich bedeutet

Seniorität bemisst sich nicht an Jahren im Lebenslauf oder an der Zahl der aufgezählten Frameworks. Man kann zehn Jahre lang programmieren, ohne je ein System in Produktion verantwortet zu haben. In der Praxis erkennen Sie erfahrene Entwickler an fünf Dingen.

Urteilsvermögen

Sie wissen, welche Entscheidungen teuer rückgängig zu machen sind (das Datenmodell, Berechtigungen, die Abrechnung, die Hosting-Region), und verwenden dort ihre Sorgfalt. Sie sagen Nein zu Features, die dem Ziel nicht dienen, und begründen es.

Architektur

Sie wählen die einfachste Struktur, die die nächsten Jahre übersteht: meist eine gut gegliederte Anwendung statt eines verteilten Systems, mit klaren Grenzen zwischen Oberfläche, Geschäftslogik und Daten. Das Warum halten sie in kurzen Entscheidungsprotokollen fest.

Testen

Automatisierte Tests und die Release-Pipeline gehören für sie zum Produkt, nicht zu den Extras für später. Jede Änderung wird auf dieselbe Weise getestet und ausgeliefert, sodass Releases Routine sind und keine Ereignisse.

Kommunikation

Sie erklären Zielkonflikte in klarer Sprache für Menschen, die keinen Code schreiben, halten Pläne und Entscheidungen schriftlich fest und sprechen schlechte Nachrichten früh an, solange Gegensteuern noch günstig ist.

Verantwortung

Ihnen ist wichtig, was nach dem Release passiert: Monitoring, Vorfälle und die Person, die den Code als Nächstes pflegt.

Ein Team muss nicht ausschließlich aus Senior-Entwicklern bestehen. Es braucht erfahrene Leute, die die teuren Entscheidungen treffen und die Arbeit reviewen, und genug davon, dass das Wissen nie in nur einem Kopf steckt.

#Eigenes Team, Agentur, Freelancer oder Team-Verstärkung

Jede der vier üblichen Arten, ein Softwareprojekt zu besetzen, ist irgendwo die richtige. Entscheidend ist, wer die Architektur verantwortet und wer das Wissen hält, wenn das Projekt endet. Eigene Einstellungen dauern in Deutschland lange: Die Bitkom-Studie vom August 2025 zählte rund 109.000 unbesetzte IT-Stellen, und ausgeschriebene IT-Stellen bleiben im Schnitt 7,7 Monate frei.

Die letzte Zeile hat in Deutschland rechtliche Tücken, denn wer die Arbeit anweist, entscheidet darüber, ob Arbeitnehmerüberlassung nach dem AÜG vorliegt. Unser Leitfaden zu IT-Fachkräften und Team-Verstärkung in Deutschland erklärt die Details.

#So bewerten Sie einen Entwicklungspartner

Jedes Angebot verspricht Qualität. Fragen Sie deshalb nach Belegen, die Sie prüfen können. Ein guter Partner freut sich über die Frage.

#Warnsignale

• Ein Festpreis für ein großes, vage beschriebenes Projekt ohne Discovery-Phase. Jemand rät, und Sie bezahlen das Raten mit Change Requests.
• Eine einzelne Zahl statt einer Spanne, bevor überhaupt jemand nach Ihren Daten, Schnittstellen oder Nutzern gefragt hat.
• Keine lauffähige Software bis zum Schluss. Wenn Sie in den ersten Wochen nichts durchklicken können, wissen Sie nicht, ob das Projekt auf Kurs ist.
• Senior-Leute im Pitch, namenlose Leute im Projekt.
• Repositories, Hosting oder App-Store-Konten, die der Dienstleister „für Sie einrichtet“, auf seinen eigenen Namen.
• Keine Fragen zu Ihrem Geschäft, Ihren Nutzern oder Ihren bestehenden Systemen.
• Keine automatisierten Tests, oder Tests „für später geplant“.
• Zurückhaltung, wenn es darum geht, Code zu zeigen, Referenzen zu nennen oder den Plan schriftlich festzuhalten.

#So bleiben die Kosten planbar

Projekte laufen aus dem Ruder, wenn unsichere Vorhaben so bepreist werden, als wären sie sicher. Die Unsicherheit lässt sich nicht beseitigen, aber Sie müssen sie nicht auf einmal bezahlen.

1. Teilen Sie die Arbeit in Phasen mit festem Umfang. Eine kurze Discovery-Phase liefert einen schriftlichen Umfang, eine Architektur und einen Plan; jede weitere Phase liefert ein nutzbares Release, und nach jeder entscheiden Sie, ob es weitergeht.
2. Verlangen Sie Schätzungen als Spannen. Eine ehrliche frühe Schätzung ist eine Spanne, die enger wird, je klarer der Umfang ist. Eine einzelne Zahl zu Beginn bedeutet, dass die Unsicherheit irgendwo versteckt ist, meist in künftigen Change Requests.
3. Fixieren Sie Termin und Budget, lassen Sie den Umfang beweglich. Ordnen Sie Features nach ihrem Wert. Wird die Zeit knapp, wandern die unwichtigsten in die nächste Phase, statt dass sich der Termin verschiebt.
4. Sehen Sie jede Woche lauffähige Software. Ein wöchentliches Release auf einer Staging-Umgebung zeigt überprüfbaren Fortschritt und bringt Missverständnisse früh ans Licht.
5. Planen Sie das Budget nach dem Launch ein. Hosting, Monitoring, Sicherheitsupdates und kleine Verbesserungen sind laufende Kosten. Klären Sie vor dem Go-live, wie sie abgedeckt werden.

Wenn Sie eine erste Version planen: Unser Leitfaden, wie Sie ein MVP bauen, das auch in Monat neun noch funktioniert, behandelt die Entscheidungen für Woche eins und einen Vierwochenplan.

#So arbeitet Bespoke IT

Bespoke IT Consultants entwickelt Web- und Mobile-Apps für Unternehmen in Deutschland, Österreich und der Schweiz und setzt erfahrene Entwickler in Kundenteams ein. Wir arbeiten so, wie dieser Leitfaden es beschreibt: Senior-Entwickler für die teuren Entscheidungen, ein schriftlicher Umfang, bevor etwas gebaut wird, jede Woche ein Release zum Durchklicken, Tests bei jeder Änderung, Hosting in Deutschland, Code, Cloud- und App-Store-Konten auf Ihren Namen und eine dokumentierte Übergabe, mit der Ihr eigenes Team arbeiten kann. Wenn Sie eine erste Zahl möchten, liefert unser Schätzer in etwa drei Minuten eine Richtwert-Spanne.