Muster, die wir bei KMU immer wieder sehen, wenn sie zum ersten Mal ein Entwicklerteam beauftragen – und wie man sie ohne eigenen CTO vermeidet.

Die meisten KMU, mit denen wir arbeiten, stellen nicht ihren hundertsten Entwickler ein. Sie beauftragen zum ersten Mal ein Softwareteam, oft ohne technischen Mitgründer im Raum. Das ist eine verletzliche Einkaufsposition – und der Markt weiß das.

Dieser Beitrag ist die ehrliche Version der Beratung, die wir solchen Kunden geben, bevor sie unterschreiben. Es ist keine aus einer Vorlage kopierte Liste von „Warnsignalen". Es sind die fünf Fehler, die wir bei KMU am häufigsten beobachten, geschrieben von Leuten, die seit einem Jahrzehnt auf der anderen Seite des Tisches sitzen.

Fehler 1: Nach dem Angebot einkaufen, nicht nach der Beziehung

Das günstigste Angebot gewinnt fast immer das erste Meeting. Das Projekt gewinnt es selten.

Ein Softwareprojekt ist keine einmalige Transaktion. Es ist eine zwei- bis fünfjährige Beziehung mit einer Codebasis. Die erste Umsetzung macht typischerweise nur 30 % der Gesamtkosten aus; die restlichen 70 % stecken in Wartung, Änderungen, Integrationen und der stillen Arbeit, die Dinge am Laufen zu halten.

Wer rein nach dem Preis der ersten Umsetzung entscheidet, optimiert also ausgerechnet den undurchsichtigsten Teil. Die anderen 70 % kommen als Überraschungsrechnungen, aufgegebener Code oder ein kompletter Neubau nach drei Jahren zurück.

Besser so:

• Lass dir von jedem Anbieter eine realistische Zweijahres-Gesamtkostenrechnung geben, inklusive Hosting, Wartungspauschale und einem groben Budget für Change Requests.
• Frage, wer am Tag 1, Tag 90 und Jahr 3 das Repository und die Infrastrukturkonten besitzt.
• Vergleiche Angebote über Gesamtkosten, nicht über den Listenpreis der ersten Phase.

Fehler 2: Das Pflichtenheft als Vertrag statt als Gespräch behandeln

Viele KMU kommen mit einem 40-seitigen Lastenheft an, bezahlt von einem Berater, und behandeln es wie ein heiliges Dokument. Jede Änderung ist eine Bedrohung für den Zeitplan. Jede Nachfrage ist ein Kampf.

Das ist die perfekte Rezeptur, um pünktlich das falsche Produkt zu bauen.

Echte Softwareprojekte lernen unterwegs. Die Anforderung aus Woche 1 ist fast nie die Anforderung, die tatsächlich in Produktion geht – weil man erst anhand einer funktionierenden Oberfläche versteht, was man wirklich brauchte. Gute Anbieter planen das ein. Sie haben Review-Punkte, prototypen die riskanten Teile früh und berechnen Änderungen ehrlich, statt so zu tun, als wären sie kostenlos.

Besser so:

• Wähle einen Anbieter, der das Pflichtenheft lesen will – und danach fragt, was noch unklar ist.
• Plane eine Änderungsreserve von 15–20 % zusätzlich zum Festpreis ein.
• Reviewe alle zwei Wochen lauffähige Software, keine Folien.

Fehler 3: Die unscheinbaren Teile weglassen

Die unscheinbaren Teile sind die, die darüber entscheiden, ob deine Software überlebt.

• Backups. Sind sie automatisiert, extern gespeichert und wurden sie real getestet?
• Zugangskontrolle. Wer kann sich als Admin einloggen – und verschwindet dieser Zugang, wenn der Anbieter geht?
• Monitoring. Erfährst du von einem Problem, bevor es deine Kunden tun?
• Dokumentation. Könnte ein anderer Entwickler den Code in einer Woche verstehen, wenn wir morgen weg wären?

Aus unserer Erfahrung: 80 % der Anbieter, die über den Preis gewinnen, streichen stillschweigend genau diese Punkte. Der Kunde merkt es erst beim ersten Ausfall, beim ersten unzufriedenen Ex-Mitarbeiter oder beim ersten Migrationsversuch.

Frage das in der Angebotsphase direkt:

• „Zeigt mir die Backup- und Restore-Prozedur, die ihr tatsächlich nutzt."
• „Zeigt mir das Monitoring-Dashboard, auf das ich Zugriff bekomme."
• „Zeigt mir das Repository und ein Beispiel eurer Dokumentation von einem anderen Kunden."

Wenn die Antwort vage bleibt, wird die Arbeit nicht gemacht.

Fehler 4: „Komplett-Individualsoftware" kaufen, wenn ein 70/30-Hybrid billiger und besser wäre

Nicht jedes Unternehmen braucht eine komplett individuell entwickelte Plattform. Manche schon. Die meisten nicht.

Ein realistisches Muster für ein erstes Softwareprojekt in KMU-Größe sieht so aus:

• 70 % Standardsoftware: ein reifes Produkt für die Standardteile (Buchhaltung, E-Mail, CRM, E-Commerce-Engine, Helpdesk).
• 30 % Individualentwicklung: die spezifischen Workflows und Integrationen, die wirklich einzigartig für dein Unternehmen sind.

Der reine Individualweg klingt verführerisch nach „wir besitzen alles". In der Praxis heißt er: Du bezahlst ein kleines Team dafür, gelöste Probleme neu zu erfinden – und übernimmst die Wartung jeder dieser Neuerfindungen für immer.

Der Hybridweg verlagert den Großteil des Risikos auf Anbieter mit tausendköpfigen Engineering-Teams und Milliardenbudgets für Verlässlichkeit. Deine Individualentwicklung konzentriert sich auf die 20 %, die wirklich dein Wettbewerbsvorteil sind.

Besser so:

• Bevor du Komplett-Individualsoftware beauftragst, lass dir von einem Anbieter ein einseitiges „Was wäre bei 70/30"-Alternativangebot schreiben.
• Behandle einen Anbieter, der Standardlösungen für die Commodity-Teile kategorisch ablehnt, als Warnsignal. Er optimiert seine Stunden, nicht dein Ergebnis.

Fehler 5: Den Ausstieg nicht ab Tag 1 mitplanen

Jede Softwarebeziehung endet irgendwann – Strategiewechsel, Fokusänderung beim Anbieter, Übernahme, neue Prioritäten. Der richtige Zeitpunkt, den Ausstieg zu planen, ist nicht die Trennung. Es sind die Flitterwochen.

Vor der Unterschrift sollten jedes KMU schriftliche Antworten auf diese Fragen haben:

• Wem gehört der Code? Im Idealfall dir, vom ersten Commit an, in einem Repository auf deinen Namen.
• Wem gehören Hosting und Domains? Im Idealfall dir, mit dem Anbieter als Mitarbeiter eingeladen.
• Wem gehören Drittkonten (E-Mail-Dienst, Zahlungsanbieter, Analytics)? Im Idealfall dir, mit dem Anbieter eingeladen.
• Wie sieht eine Übergabe an einen anderen Entwickler aus? Seriöse Anbieter haben dafür ab Tag 1 ein einseitiges Übergabedokument.

Ein Anbieter, der bei einer dieser Fragen zusammenzuckt, sagt dir etwas Wichtiges. Einer, der sie willkommen heißt, genauso.

Wie wir unsere eigenen Projekte führen

Zur Transparenz: In unseren Projekten gehören Repository und Hosting standardmäßig dem Kunden, es gibt ein veröffentlichtes Übergabedokument und eine Wartungspauschale, die beide Seiten mit 30 Tagen Frist kündigen können. Wir glauben nicht an Lock-in als Kundenbindung. Wenn unsere Arbeit gut ist, bleibst du, weil du willst. Wenn nicht, solltest du sauber gehen können.

Das ist die Version der Softwarebranche, bei der wir selbst einkaufen würden – also versuchen wir, diese Version zu sein.

Zusammenfassung

Wer zum ersten Mal ein Softwareteam beauftragt, sollte sich merken:

• Das Angebot ist 30 % der wahren Kosten. Bewerte über zwei Jahre, nicht über die erste Rechnung.
• Behandle das Pflichtenheft als Ausgangshypothese, nicht als Vertrag.
• Streiche niemals Backups, Monitoring, Zugangskontrolle und Dokumentation.
• Prüfe ein 70/30-Hybridmodell, bevor du Komplett-Individualsoftware bestellst.
• Regle Eigentum und Ausstieg vor der Unterschrift, nicht danach.

Wenn du eine Zweitmeinung zu einem Angebot haben willst, das du schon bekommen hast, lesen wir es gerne mit dir durch. Kein Verkaufsgespräch – wir sagen dir ehrlich, ob die Zahlen für die beschriebene Arbeit plausibel sind.

Original Source: Fünf teure Fehler, die KMU beim ersten Softwareteam machen