Die Wahl eines Softwaredienstleisters ist kein Kauf von der Stange. Sie kaufen das Versprechen einer Arbeit, die Monate dauert und deren Ergebnis jahrelang in Ihrem Unternehmen laufen wird. Deshalb endet die Frage, wie Sie einen Softwaredienstleister vor Vertragsabschluss prüfen, nicht beim Vergleich von drei PDF-Dateien mit Preisen. Es geht um etwas anderes: Steht auf der anderen Seite ein Team, das Ihr geschäftliches Problem versteht, die Grenzen der Technologie kennt und sagen kann, was nicht machbar ist? Bei Web Systems beschäftigen wir uns seit 2006 mit der Entwicklung individueller Software nach Maß: mit Web- und Mobilanwendungen, B2B-Systemen, API-Integrationen und KI-Lösungen. Wir haben also vorbildlich geführte Projekte gesehen und auch solche, die wir auf halbem Weg von jemand anderem übernommen haben. Im Folgenden lesen Sie, was gute Dienstleister tatsächlich von geschickten Verkäufern trennt.
Inhaltsverzeichnis
Was Sie wirklich suchen, bevor Sie Angebote prüfen
Die Prüfung beginnt bei Ihnen, nicht beim Dienstleister. Bevor Sie die Kompetenz von irgendjemandem bewerten, müssen Sie benennen, was Sie bestellen. Ein MVP zur Validierung einer Marktidee, ein internes B2B-System, das die nächsten zehn Jahre arbeiten soll, die Modernisierung einer bestehenden Anwendung, die seit acht Jahren läuft - das sind drei völlig verschiedene Vorhaben. Anderer Ansatz, anderes Tempo, andere Leute.
Ein Prototyp belohnt Geschwindigkeit und die Bereitschaft, nach den ersten Tests mit Nutzern die Hälfte des Codes wegzuwerfen. Ein System, das sich mit einem ERP verbindet, belohnt Vorsicht, Kenntnis der Datenstrukturen und Geduld in den Gesprächen mit dem Anbieter jenes Systems. Ein Team, das im ersten Szenario glänzt, ist im zweiten oft nur mittelmäßig. Und umgekehrt. Wenn Sie diese Unterscheidung nicht treffen, bitten Sie alle um eine „Anwendung” und erhalten Angebote, die sich inhaltlich schlicht nicht vergleichen lassen.
Und dann schnappt die typische Falle zu. Da die Dokumente ähnlich aussehen, fällt die Entscheidung nach dem Betrag. Nur entsteht der Preisunterschied meist nicht aus der Gier der anderen Seite, sondern aus einem unterschiedlichen Verständnis des Umfangs. Der eine Dienstleister hat ein Formular kalkuliert. Der andere dasselbe Formular plus die Validierung der Daten gegen ein externes Register, die Fehlerbehandlung und ein Administrationspanel zum Korrigieren von Fehleingaben.
Warnsignal: Der Dienstleister nennt eine konkrete Zahl, bevor er nach dem Datenvolumen, der Zahl der Nutzer, den nötigen Integrationen und danach fragt, was mit der Anwendung in der Hochsaison passiert. Ein Angebot ohne Fragen ist ein Angebot für etwas anderes als Ihr Projekt.
Tipp: Schreiben Sie auf einer Seite drei Dinge auf - das geschäftliche Problem, das gelöst werden soll, die Prozesse, die die Anwendung abdecken soll, und die Systeme, mit denen sie kommunizieren muss. Dieses Blatt bringt für die Qualität der Angebote mehr als eine zwanzigseitige Spezifikation, die ohne Technologiekenntnis geschrieben wurde. Schicken Sie es an alle angefragten Firmen und beobachten Sie, wer nachfragt und wer sofort eine Preisliste schickt.
Erfahrung, die man im Portfolio nicht sieht
Ein Portfolio zeigt das visuelle Ergebnis, nicht die technische Schwierigkeit. Ein ansehnlicher Shop ist oft die Standardeinführung eines fertigen Shopsystems, und ein grafisch unscheinbares Logistikpanel das schwierigste Projekt der Firmengeschichte, weil es Lagerbestände zwischen vier Systemen in Echtzeit synchronisiert. Screenshots geben das nicht wieder.
Bitten Sie statt um eine Galerie um eine Beschreibung der Herausforderungen. Die Frage lautet: Was war in diesem Projekt am schwierigsten und wie wurde es gelöst. Die Antwort „alles lief glatt” ist verdächtig. IT-Projekte laufen nicht glatt, sie laufen bestenfalls gut gesteuert. Ein Dienstleister, der von einer falschen Architekturannahme vom Beginn der Arbeiten erzählen kann und davon, wie er sie korrigiert hat, sagt Ihnen mehr als zwanzig Logos auf der Website.
Fragen Sie gesondert nach Projekten, die über Jahre betreut werden. Ein System zu übergeben und zu verschwinden ist nicht dasselbe wie sieben Jahre Betreuung einer wachsenden Anwendung, in denen sich Framework-Versionen, rechtliche Anforderungen und die APIs der Partner geändert haben. Lange Kundenbeziehungen lassen sich schwerer vortäuschen als einmalige Umsetzungen.
- Kontinuität des Teams - ob die Leute, die das Projekt von vor drei Jahren gebaut haben, noch in der Firma arbeiten oder von ihnen nur der Name im Portfolio geblieben ist.
- Alter der Firma - ein Unternehmen, das seit weit über zehn Jahren besteht, hat schon mehrere technologische Umbrüche und mindestens eine wirtschaftliche Abschwächung hinter sich.
- Die Art, über Misserfolge zu sprechen - die konkrete Geschichte eines behobenen Fehlers wiegt mehr als die Behauptung, es gebe keine Ausfälle.
Prüfen Sie Referenzen mit Augenmaß. Ein Gespräch mit dem Kunden eine Woche nach der Abnahme bringt Begeisterung. Ein Gespräch ein Jahr später - die Wahrheit über die Wartungskosten, die Reaktionszeit auf Meldungen und darüber, ob überhaupt jemand ans Telefon geht, wenn das Projekt nicht mehr neu ist. Fragen Sie nach diesem zweiten Zeitpunkt.
Technische Fragen, die Dienstleister aussieben
Sie müssen kein Programmierer sein, um Fragen zu stellen, die aussieben. Es reicht, wenn Sie darauf hören, ob die Antwort eine Begründung enthält oder nur Namen von Technologien. Bitten Sie um eine Beschreibung der vorgeschlagenen Architektur und um eine Erklärung, warum gerade diese. Ein Monolith ist oft die richtige Wahl für ein System, das von dreißig Nutzern bedient wird, und seine Zerlegung in Microservices kann Betriebskosten erzeugen, ohne jeden geschäftlichen Nutzen.
Der zweite Bereich sind Sicherheit und personenbezogene Daten. Fragen Sie, wie die Authentifizierung funktioniert, wo Passwörter und Tokens gespeichert werden, wer Zugriff auf die Produktionsdatenbank hat und wie die Rechteverteilung in der Anwendung aussieht. Wenn das System personenbezogene Daten berührt, sollten Worte über Verschlüsselung, Aufbewahrungsfristen, Zugriffsprotokolle und die Minimierung der erhobenen Informationen fallen.
Der dritte Bereich sind Integrationen. Also die Stelle, an der die meisten Budgets verschwinden. Der API-Aufruf selbst ist einfach. Schwierig wird es bei Anfragelimits, vorübergehender Nichterreichbarkeit des Partners, doppelten Ereignissen und Daten, die unvollständig angekommen sind.
- Was passiert, wenn die externe API mit einem Fehler antwortet oder gar nicht antwortet - gibt es eine Warteschlange, eine Wiederholung, ein Limit an Versuchen.
- Wie erkennen Sie doppelte Ereignisse, damit eine Transaktion nicht zweimal gebucht wird.
- Wo landen die Datensätze, die die Validierung abgelehnt hat, und wer sieht sie sich an.
- Wie verhält sich das System, wenn das Datenvolumen um ein Mehrfaches wächst - was wird dann zum Engpass.
Fragen Sie auch nach der Arbeitshygiene: automatische Tests, CI/CD, eine getrennte Testumgebung, Ereignisprotokollierung und Monitoring. Ein Dienstleister, der Änderungen direkt in die Produktion einspielt, spart jetzt und stellt Ihnen die Rechnung später. Vielfach erlebt. Bei Projekten auf Basis künstlicher Intelligenz fragen Sie nach den Token-Kosten bei realem Traffic, nach Qualität und Aufbereitung der Eingangsdaten sowie nach der Art der Ergebniskontrolle - ein Modell, das im Kundenservice unvorhersehbare Antworten erzeugt, braucht einen Rahmen, nicht nur einen Prompt.
Angebot, Zeitplan und Abrechnungsmodell
Fixed Price lockt mit Planbarkeit, funktioniert aber nur bei einem Umfang, der so genau beschrieben ist, dass beide Seiten ihn gleich verstehen. Je genauer die Beschreibung, desto mehr Analysearbeit vor dem Start. Und auch diese Arbeit kostet. Ein Dienstleister, der bei vagen Anforderungen einem Festpreis zustimmt, hat sich entweder mit einem dicken Puffer abgesichert oder plant bei jeder Änderung einen Nachtrag.
Time and Material gibt Flexibilität und bildet den Aufwand ehrlich ab. Es verlangt jedoch Vertrauen und ein Reporting, das sich überprüfen lässt. Ein sinnvoller Kompromiss ist oft die Teilung des Projekts: eine bezahlte Analyse und ein technisches Konzept in der ersten Phase und erst auf dieser Grundlage ein verbindliches Angebot für die Umsetzung. Sie geben dann einen kleinen Teil des Budgets aus, um zu erfahren, was der Rest wirklich kostet, und können mit der Dokumentation zu einem anderen Team gehen.
Ein sehr niedriges Angebot bedeutet selten außergewöhnliche Effizienz. Häufiger bedeutet es einen eng verstandenen Umfang, ausgelassene Tests, eine fehlende Datenmigration oder die Annahme, dass Sie Inhalte, Grafiken und die Konfiguration der Infrastruktur selbst liefern. Rechnen Sie das später zusammen und vergleichen Sie es mit dem Angebot, das teuer wirkte.
Eine Schätzung ohne Aufteilung in Phasen lässt sich nicht überprüfen. Ein Betrag für das Ganze erlaubt keine Einschätzung, ob überhaupt jemand an das Administrationspanel oder an den Import der Altdaten gedacht hat. Bitten Sie um eine Aufschlüsselung nach Modulen und Funktionen, mit gesondert ausgewiesener Zeit für Analyse, Tests, Inbetriebnahme und Projektübergabe.
Legen Sie auch fest, was bei einer Änderung des Umfangs während der Arbeiten passiert. Denn die Änderung wird kommen. Nötig ist ein einfacher Weg: Meldung, Kalkulation der Änderung, Freigabe, Umsetzung. Ohne ihn wird jede Anpassung zu einer Verhandlung von null an.
Tipp: Vergleichen Sie Angebote nach den Annahmen, nicht nach dem Endbetrag. Tragen Sie in einer Tabelle ein, was jeder Dienstleister als enthalten betrachtet und was er stillschweigend übergangen hat. Die Unterschiede in dieser Tabelle erklären die Preisunterschiede besser als jedes Verkaufsgespräch.
Code, Daten und Lizenzen - wem gehört was nach Projektende
Das ist der am häufigsten unterschätzte Teil des Vertrags. Und zugleich der, der ein Unternehmen auf Jahre blockieren kann. Die Bezahlung der Softwareerstellung bedeutet nicht automatisch den Erwerb der Rechte daran. Die Übertragung der urheberrechtlichen Vermögensrechte muss ausdrücklich festgehalten sein, mit aufgezählten Verwertungsfeldern, und auch das Recht umfassen, die Software zu ändern und andere Unternehmen mit Änderungen zu beauftragen. Ohne diesen letzten Punkt besitzen Sie formal einen Code, den Sie nicht frei weiterentwickeln dürfen.
Genauso wichtig ist der Zugang zum Repository ab dem ersten Arbeitstag, nicht erst nach der Endabnahme. Laufender Einblick in den Code ist kein Misstrauen, sondern eine elementare Absicherung der Kontinuität. Wenn die Zusammenarbeit mitten im Projekt endet, haben Sie alles, was bis dahin entstanden ist, samt Änderungshistorie.
Die Infrastruktur sollte Ihnen gehören. Die Domain auf Ihr Unternehmen registriert, die Cloud-Konten auf Ihre Adresse angelegt, die API-Schlüssel für externe Dienste auf Ihre Konten ausgestellt und der Dienstleister als Nutzer mit passenden Berechtigungen hinzugefügt. Die umgekehrte Konstellation, in der alles am Konto der Agentur hängt, macht aus einem gewöhnlichen Anbieterwechsel eine Verhandlung.
- Lizenzen der Komponenten - bitten Sie um eine Liste der externen Bibliotheken und ihrer Lizenzen, vor allem bei Software, die Sie verkaufen oder Kunden bereitstellen wollen.
- Datenexport - es muss einen Weg geben, den vollständigen Datenbestand in einem lesbaren Format herauszuholen, ohne ein zusätzliches Werkzeug zu schreiben.
- Übergabedokumentation - eine Beschreibung der Architektur, eine Anleitung zum Aufsetzen der Umgebung und eine Liste der Abhängigkeiten, damit ein anderes Team das Projekt ohne Archäologie im Code übernehmen kann.
Prüfen Sie auch, ob im Projekt geschlossene Eigenkomponenten des Dienstleisters stecken, die nur für die Dauer der Zusammenarbeit lizenziert sind. Das ist zulässig, aber Sie müssen es vor der Unterschrift wissen und nicht erst beim Versuch einer Migration.
Vertragsklauseln, die das Projekt retten
Ein Vertrag ist kein Dokument für den Konfliktfall. Er hält fest, wie beide Seiten die Zusammenarbeit verstehen, und deshalb lohnt es sich, ihm vor dem Start Zeit zu widmen, solange die Beziehung noch gut ist. An erster Stelle: die Definition der Abnahme. „Fertig” muss eine konkrete Bedeutung haben - ein Satz von Testszenarien, die bestanden werden, der Betrieb auf der benannten Umgebung, die übergebene Dokumentation, eine benannte Person, die die Abnahme bestätigt, und eine Frist für Anmerkungen.
Eine nur schlagwortartig beschriebene Gewährleistung funktioniert nicht. Sie brauchen eine Einteilung der Fehler in Kategorien und zugeordnete Reaktionszeiten. Ein Ausfall, der den Verkauf blockiert, ist etwas anderes als ein verschobener Button, und der Vertrag sollte das unterscheiden. Legen Sie außerdem fest, zu welchen Uhrzeiten diese Zeiten gelten und was außerhalb davon passiert.
Beschreiben Sie die Regeln der Kommunikation. Wer auf Seiten des Dienstleisters für das Projekt verantwortlich ist, wer diese Person im Urlaub vertritt, wie oft Sie einen Fortschrittsbericht bekommen und über welchen Kanal Sie Anmerkungen melden. Projekte zerfallen häufiger am Informationschaos als an technischen Schwierigkeiten. Eine entscheidungsbefugte Person auf jeder Seite spart Wochen.
Wenn die Anwendung personenbezogene Daten verarbeitet, ist ein Auftragsverarbeitungsvertrag nötig, der den Umfang der Daten, den Zweck, die Subunternehmer, die Serverstandorte und die Regeln für die Löschung der Daten nach Ende der Zusammenarbeit festlegt. Er wird oft als Formalität behandelt, die man im Vorbeigehen unterschreibt. Dabei ist er eine echte Absicherung im Falle eines Vorfalls.
Zum Schluss die Ausstiegsbedingungen. Halten Sie fest, was bei Auflösung des Vertrags passiert: Übergabe von Code, Daten, Zugängen, Dokumentation und Konfiguration innerhalb einer bestimmten Frist, Abrechnung der geleisteten Arbeiten. Eine gut beschriebene Trennung wird meist nie gebraucht, aber ihr Fehlen macht aus einem gewöhnlichen Anbieterwechsel einen Streit, der sich über Monate zieht.
Wartung nach dem Start - der am häufigsten übersehene Teil der Auswahl
Eine Anwendung beginnt erst nach dem Start richtig zu kosten. Dann kommen Aktualisierungen der Bibliotheken, Sicherheitspatches, Änderungen an den APIs der Partner, die Umbauten an den Integrationen erzwingen, steigende Infrastrukturrechnungen bei mehr Traffic und kleine Korrekturen, gemeldet von Nutzern, die das System endlich wirklich verwenden. Ein Dienstleister, der im Verkaufsgespräch über diese Phase schweigt, hat entweder nie etwas über längere Zeit betreut oder umgeht bewusst ein unbequemes Thema.
Monitoring, Backups und das Verfahren zur Wiederherstellung sollten vor dem Start festgelegt sein, nicht nach dem ersten Ausfall. Ein Backup allein bedeutet nichts, wenn nie jemand geprüft hat, ob sich daraus ein funktionierendes System wiederherstellen lässt. Fragen Sie direkt, wie der Wiederherstellungstest aussieht und wie lange die Rückkehr zum Betrieb nach einem schweren Vorfall dauert.
Legen Sie fest, wer am Freitagabend auf einen Ausfall reagiert und zu welchen Bedingungen. Die Antwort „wir werden uns schon einigen” bedeutet, dass es kein Verfahren gibt. Sie müssen wissen, ob es einen Bereitschaftsdienst gibt, wie man ihn auslöst, was er kostet und was er abdeckt.
Prüfen Sie auch die Fähigkeit zur Rückkehr. In einem halben Jahr werden Sie ein Reporting-Modul ergänzen oder ein neues Zahlungssystem anbinden wollen. Eine Firma, die ausschließlich mit neuen Projekten beschäftigt ist und keinen Prozess für die Betreuung früherer Kunden hat, hat dann womöglich keine freien Leute.
Typischer Fehler: die Wahl des günstigsten Dienstleisters für den Bau mit der Annahme, dass jemand anderes die Wartung übernimmt. Die Übernahme von fremdem Code ohne Dokumentation, Tests und Beschreibung der Entwurfsentscheidungen kostet mehr als die anfängliche Ersparnis, und das neue Team muss zuerst verstehen, was es nicht anfassen darf. Behandeln Sie Bau und Wartung als eine Entscheidung.
Zusammenfassung
Einen Softwaredienstleister vor Vertragsabschluss zu prüfen heißt, seine Art zu bewerten, über das Problem nachzudenken, und nicht Preislisten und Projektgalerien zu vergleichen. Ein schönes Portfolio und ein attraktiver Betrag sagen Ihnen nicht, wie sich das Team verhält, wenn eine Integration Fehler zurückgibt, das Datenvolumen über die Annahmen hinauswächst oder sich die Anforderungen mitten in der Arbeit ändern. Das sagen Ihnen dagegen die Antworten auf Fragen zu Architektur, Sicherheit, Ausnahmebehandlung und Wartung.
Das größte Risiko steckt nicht in der grafischen Ebene. Es steckt in den Integrationen, der Datenqualität, den Rechten am Code und in dem, was nach dem Start passiert. Sichern Sie diese vier Bereiche im Gespräch und im Vertrag ab, der Rest lässt sich unterwegs korrigieren. Ein guter Partner spricht von sich aus schon in der Angebotsphase über Grenzen, Kompromisse und Wartungskosten, weil ihm ein schwieriges Gespräch jetzt lieber ist als ein Konflikt in einem Jahr.
Planen Sie ein MVP, eine Web- oder Mobilanwendung, eine API-Integration, die Automatisierung von Prozessen, eine KI-basierte Lösung oder die Modernisierung eines Systems, das mit dem Unternehmen nicht mehr Schritt hält? Schreiben Sie uns. Wir sehen uns gern die Angebote an, die auf Ihrem Schreibtisch liegen, und sagen Ihnen, wonach Sie fragen sollten, bevor Sie etwas unterschreiben.
