Wie wählt man ein Softwarehaus - und worauf sollte man achten?

Prüfen Sie bei der Wahl eines Softwarehauses drei Dinge: Verantwortung für den Produktivbetrieb, Zusammensetzung des Projektteams und die Bedingungen für die Übergabe des Systems. Portfolio und Technologie helfen erst dann, wenn sie sich auf eine ähnliche Größenordnung, ein vergleichbares Risiko und dieselbe Lebensphase des Produkts beziehen.

Wir schreiben das als Dienstleister, daher dürfen Sie skeptisch sein. Deshalb sind die folgenden Fragen so formuliert, dass Sie sie auch uns stellen können – und dass eine schlechte Antwort sichtbar wird.

Drei Fragen, die am meisten sagen

1. Was betreiben Sie heute produktiv, und wie erfahren Sie von einer Störung?

„Wir haben es gebaut“ und „wir betreiben es“ sind unterschiedliche Kompetenzen. Die Frage nach einem laufenden System macht Monitoring, Reaktion auf Vorfälle, Backups und Verantwortung nach der Einführung sichtbar – Aspekte, die ein Portfolio allein kaum zeigt.

Eine gute Antwort ist konkret: Welchen Umfang betreibt der Dienstleister, wie überwacht er den Dienst, wer reagiert, in welcher Zeit und was bleibt Verantwortung des Kunden? Vertraulichkeit kann den Projektnamen einschränken, sollte aber eine Beschreibung des Prozesses nicht verhindern.

Bei uns ist die auf TimescaleDB basierende Analyseplattform ein Beispiel: ein auf einem VPS eingeführtes System mit kontinuierlich arbeitenden Kollektoren, Monitoring und regelmäßigen Berichten. Monitoring soll Unterbrechungen erkennen, nicht hundertprozentige Verfügbarkeit versprechen.

2. Wer wird meinen Code konkret schreiben?

Die Frage betrifft die Transparenz des Liefermodells. Ein eigenes Team, Partner und Subunternehmer können ein gutes Ergebnis liefern, wenn klar ist, wer für Architektur, Qualitätsprüfung, Kontinuität und die Rechte am erzeugten Code verantwortlich ist.

Fragen Sie nach: Wird die Person aus dem Verkaufsgespräch im Projekt arbeiten? Wie viele Projekte führt sie gleichzeitig? Wer übernimmt, wenn diese Person Urlaub hat?

3. Wie sieht die Trennung aus?

Diese Frage wird leicht übergangen, obwohl die Bedingungen des Ausstiegs über die Abhängigkeit vom Dienstleister entscheiden. Prüfen Sie den Ausstieg genauso sorgfältig wie den Start. Was erhalten Sie bei Ende der Zusammenarbeit?

• das Repository mit Historie und Rechten am für den Kunden erstellten Code, einschließlich einer Lizenzübersicht der Abhängigkeiten;
• Zugang zu Server, Domain und kritischen Diensten auf Kundenkonten oder eine dokumentierte Übergabeprozedur;
• Dokumentation, die ein anderes Team benötigt, um den vereinbarten Umfang zu starten und zu übernehmen;
• Daten in einem exportierbaren Format.

Konten für kritische Dienste sollten dem Kunden gehören oder eine vereinbarte Übergabeprozedur haben. Wenn der Dienstleister den Zugriff aus betrieblichen Gründen verwaltet, sollte der Vertrag die Wiedererlangung der Kontrolle und den Datenexport beschreiben.

Neun ergänzende Fragen

4. Wie kalkulieren Sie, und was passiert bei einer Änderung des Umfangs? Die Antwort „Wir geben Bescheid“ erhöht das Konfliktrisiko. Ein Verfahren für Umfangsänderungen sollte vereinbart sein.
5. Was umfasst „Einführung“? Klären Sie Verantwortung für Monitoring, Backups, getestete Wiederherstellung, Zertifikate und Reaktion auf Vorfälle. Fehlen diese Punkte, kann das einen Pilot bedeuten oder Pflichten auf den Kunden übertragen – das sollte offen sein.
6. Wie oft sehe ich eine funktionierende Version? Abnahme erst am Ende erhöht die Kosten einer späten Entdeckung von Abweichungen. Vereinbaren Sie einen zur Projektdauer passenden Demonstrationsrhythmus und Zeitpunkte, an denen sich die Richtung noch ändern lässt.
7. Was geschieht, wenn sich nach zwei Wochen herausstellt, dass die Idee geändert werden muss? Damit prüfen Sie, ob der Prozess Lernen während der Umsetzung überhaupt vorsieht.
8. Wie testen Sie? Es geht nicht um eine Werkzeugliste, sondern darum, ob die geldrelevante Logik automatisierte Tests hat und ob jemand sie vor der Einführung ausführt.
9. Wer entscheidet auf Ihrer Seite über die Architektur? Sie möchten wissen, ob eine Person für Konsistenz verantwortlich ist oder jede nach eigenem Stil schreibt.
10. Wie sehen Betrieb und Kosten aus? Bitten Sie um Verantwortungsumfang und Reaktionszeit statt um ein allgemeines „Wir sind verfügbar“.
11. Wo werden unsere Daten verarbeitet? Bei KI-Projekten ist das besonders wichtig – wir erläutern es in Datensicherheit bei der KI-Einführung.
12. Können Sie ein schwieriges Projekt beschreiben und sagen, was Sie am Prozess geändert haben? Ein Dienstleister darf den Kunden möglicherweise nicht nennen, sollte aber Problem, Entscheidung und eingeführte Schutzmaßnahme konkret schildern können. Um eine Referenz sollten Sie erst mit Zustimmung ihres Urhebers bitten.

Sieben Warnsignale

• Kalkulation ohne klare Annahmen. Ein erster Rahmen nach einer E-Mail kann der Qualifikation dienen, ein verbindliches Angebot sollte jedoch Umfang, Ausschlüsse und das Änderungsverfahren beschreiben.
• Keine Fragen zu Ergebnis und Risiken. Prüfen Sie, ob der Dienstleister Problem, Daten, Integrationen und Fehlerkosten versteht – nicht nur eine Funktionsliste.
• Keine technische Prüfung vor der Verpflichtung. Der Vertrieb kann das Gespräch führen, aber Machbarkeit und wichtige Annahmen sollten durch eine technisch verantwortliche Person bewertet werden.
• Code und kritische Zugänge liegen ausschließlich beim Dienstleister, ohne Übergabeverfahren. Siehe die dritte Frage.
• Der Tech-Stack als alleiniges Argument. „Wir arbeiten mit der neuesten Technologie“ beantwortet Ihre Problemfrage nicht.
• Ein Termin ohne Puffer. Das Versprechen „sicher in vier Wochen“ ohne Vorbehalte deutet darauf hin, dass niemand Risiken kalkuliert hat.
• Kein Verfahren zur Klärung des Umfangs. Nicht jedes kleine Projekt braucht ein vollständiges Discovery, doch vor dem Coden müssen zumindest Abnahmekriterien, Annahmen und ein Entscheidungsverantwortlicher entstehen. Bei größerer Unsicherheit empfehlen wir ein Product Discovery vor dem Anwendungsbau.

Großer oder kleiner Dienstleister?

Es gibt keine einheitliche Antwort. Die folgenden Unterschiede sind häufige Organisationsmodelle, keine durch die Unternehmensgröße garantierten Ergebnisse:

	Kleineres Studio	Großes Softwarehaus
Kontakt mit einer technischen Person	oft direkt	hängt von der Projektbesetzung ab
Änderung des Umfangs	kann schnell, aber weniger formalisiert sein	hat häufiger einen formalen Prozess
Kontinuität des Teams	Vertretungsplan und Dokumentation prüfen	Fluktuation und Teamzusage prüfen
Prozesse und SLA	können individuell angepasst sein	sind häufiger standardisiert
Passung zum Projekt	hängt von Kompetenz und Verfügbarkeit ab	hängt von Kompetenz und Mindestvertragsgröße ab

In einem kleineren Studio kann die Abhängigkeit von einer einzelnen Person ein Risiko sein. Fragen Sie daher nach Vertretung, Dokumentation und Übergabeweg. In unserem Modell geht das Repository im vertraglich beschriebenen Umfang an den Kunden; auch die Eigentümerschaft an Konten und das Übergabeverfahren für kritische Zugänge vereinbaren wir für jedes Projekt. Jede Übernahme braucht dennoch Zeit, um das System kennenzulernen.

Was Sie nicht prüfen sollten

Drei Dinge nehmen in Gesprächen viel Raum ein und sagen wenig aus:

• Nur die Zahl der Projekte. Hundert einfache Unternehmenswebsites sind ein schwacher Beleg für die Fähigkeit, ein System mit anderem Risiko und anderer Größe zu bauen; prüfen Sie Umfangsähnlichkeit und Verantwortung für den Produktivbetrieb.
• Die Liste von Technologien auf der Website. Einen Namen in die Fußzeile zu schreiben kostet nichts.
• Nur die Teamgröße. Fragen Sie nach den Ihrem Projekt zugeordneten Personen, ihrer Verfügbarkeit, Verantwortung und dem Vertretungsplan. Die Gesamtzahl der Mitarbeitenden beantwortet diese Fragen nicht.

Häufige Fragen

Lohnt es sich, für eine Kalkulation zu bezahlen?

Ein erstes Gespräch und ein Preisrahmen können kostenlos sein. Ein separates Produkt ist die Analyse, die einen Umfang, eine Architektur oder einen Plan erzeugt, der unabhängig vom Dienstleister verwendbar ist. Bei uns sind Gespräch und Kalkulation kostenlos, kostenpflichtig ist das Discovery.

Wie vergleicht man Angebote, die sich um ein Vielfaches unterscheiden?

Zuerst nach Umfang, Annahmen und Verantwortung, erst danach nach Preis. Die Unterschiede entstehen oft aus einem anderen Verständnis derselben Worte und aus der Frage, ob das Angebot bis zum Produktivbetrieb reicht. Das erläutern wir in Was kostet eine Webanwendung?.

Was, wenn ich bereits einen Dienstleister habe und etwas nicht funktioniert?

Beginnen Sie mit drei Dingen: Wo liegt das Repository, auf wessen Konten liegen die Zugänge, und was ist konkret produktiv eingeführt? Die Antworten bestimmen Ihre realen Optionen.

---

Bitten Sie vor Projektbeginn um eine klare Teamzusammensetzung, Verantwortung für Code Reviews und Übergabebedingungen. Sehen Sie sich unseren Prozess, den Tech-Stack und von Grund auf gebaute Anwendungen an – oder stellen Sie uns diese zwölf Fragen.