[Inhaltsverzeichnis]Inhaltsverzeichnis anzeigen
Wir haben ~200 Anbieter für unsere eigenen Produkte bewertet. Wir selbst wurden ~150 Mal bewertet. Nach 10 Jahren: ich habe für Teams programmiert und von Teams gekauft. Der Abstand zwischen good-on-paper und good-in-reality ist enorm.
Dieses Framework ist keine akademische Liste. Es fiel aus konkreten Projekten heraus, in denen entweder etwas schiefging oder etwas besser lief, als irgendjemand erwartet hatte. Jedes Kriterium hat einen Grund zu existieren und eine Methode zur Überprüfung. Das vollständige Angebot sehen Sie in der Dienstleistungsübersicht, reale Umsetzungen in den Projekten.
Scorecard für die Software-House-Auswahl — 10 Kriterien
Diese zehn Kriterien stammen aus Niederlagen, nicht aus der Theorie. Kriterium 3 (Teamzusammensetzung) — ein Junior-only-Team ist uns bei einem Projekt im Wert von 280k PLN abgestürzt. Kriterium 6 (Rescue) — jeder reife Shop hat Projekte hinter sich, die er reanimieren musste. Wenn ein Anbieter solche Geschichten nicht hat, verkauft er Ihnen nur die geglättete Version.
Wie bewertet man das Portfolio eines Anbieters?
Der Anbieter zeigt 5 Case Studies, alle Erfolge — rote Flagge. Er zeigt einen Misserfolg und erklärt, wie er ihn behoben hat — dann hören Sie zu. Das ist die einzige Messgröße, die funktioniert.
Bitten Sie um 3-5 Case Studies aus Ihrer Branche oder mit vergleichbarer Komplexität. Keine Präsentationen, nur Konkretes mit Metriken. Wie lange dauerte das Projekt? Wie hoch war das Budget? Was lief schief? Ergänzen Sie einen zweiten Test: bitten Sie um den Kontakt eines Kunden aus einem Projekt mit Problemen. Eine Ablehnung ist Disqualifikation.
2. Entwicklungsprozess — Wiederholbarkeit vor Kreativität
Fragen Sie: Wie sieht Ihr typischer Sprint aus? Wer übernimmt die Rolle des Product Owners? Wie berichten Sie über Fortschritte? Wie gehen Sie mit Change Requests um? Ein reifes Software House beschreibt seinen Prozess in 5 Minuten, weil er wiederholbar ist. Ein schlechtes sagt „wir passen uns an den Kunden an”, was meistens „kein Prozess” bedeutet.
Prüfen Sie, ob eine Definition of Done existiert, ob Code Reviews stattfinden, ob es eine CI/CD-Pipeline ab Tag eins gibt. Das ist Hygiene, kein Luxus. In 2026 ist das Fehlen automatisierter Tests und Deployments ein Signal, dass die Firma in 2015 steckengeblieben ist.
3. Team — lernen Sie die Menschen kennen, nicht die Folien
In der Verkaufsphase sprechen Sie mit dem Vertrieb und einem Senior-Architekten. Aber wer schreibt tatsächlich Ihren Code? Bestehen Sie darauf, das dem Projekt zugewiesene Team kennenzulernen. Prüfen Sie das Verhältnis von Senioren zu Junioren. Ein Junior-only-Team mit einem einzigen Senior-Mentor ist ab 500 Arbeitsstunden ein Rezept für eine Katastrophe — wir haben das am eigenen Leib getestet und es hat uns eine Viertelmillion gekostet.
Fragen Sie nach der Fluktuation. Über 25% pro Jahr bedeutet, dass sich Ihr Team mitten im Projekt ändert. Jeder Entwicklerwechsel kostet 2-4 Wochen Produktivität, und das Kontextwissen verschwindet mit ihm.
4. Kommunikation — Frequenz und Werkzeuge
Scheinbar Kleinigkeiten erzeugen 80% der Frustration in IT-Projekten. Mindeststandard: täglicher asynchroner Status, wöchentlicher Call mit Demo, Reaktionszeit unter 4 Arbeitsstunden.
Wir haben einem Anbieter Freitag 16:00 Uhr eine technische Frage gestellt. Antwort am Dienstag. Diese Delta hat den Deal getötet. Ein Kommunikationstest ist mehr wert als zehn Versprechen im Angebot.
5. Umgang mit Misserfolgen — Reifeprüfung
Fragen Sie direkt: erzählen Sie von einem Projekt, das nicht funktioniert hat. Was lief schief? Was haben Sie nach diesem Misserfolg am Prozess geändert? Eine Firma, die behauptet, nie ein gescheitertes Projekt gehabt zu haben, lügt oder hat nicht genug Erfahrung. Suchen Sie Partner, die offen über Misserfolge sprechen — das bedeutet Lernkultur, nicht Marketing.
6. Rescue Capability — die Fähigkeit zu retten
Hat die Firma Erfahrung mit der Übernahme von Projekten anderer Teams? Eine Rescue Mission erfordert schnelles Audit, Stabilisierung und Refactoring. Diese Kompetenzen werden auch in Ihrem Projekt nützlich, wenn unvorhergesehene Probleme auftauchen — und sie werden auftauchen.
Bei Do More Soft machen Rescue Missions etwa 30% der Projekte aus. Jede einzelne hat uns mehr über Software Engineering beigebracht als zehn Greenfield-Projekte. Dieses Wissen übersetzt sich direkt in die Qualität neuer Umsetzungen.
7. Preistransparenz
Ehrlichkeit bei der Preisgestaltung bedeutet zu erklären, wie diese Zahl kalkuliert wurde. Wie viele Stunden für welche Module? Welcher Risikopuffer? Was ist im Scope, was nicht? Firmen, die eine Zahl ohne Aufschlüsselung nennen, kalkulieren „über den Daumen” oder verstecken bewusst Kosten. Bei ernsthaften Projekten starten Sie mit einem formalen Consulting- und Audit-Engagement — das strukturiert die Kalkulation und eliminiert Überraschungen.
8. Technologische Passung
Es geht nicht um React vs. Vue. Es geht darum, ob der Stack zu Ihrem Kontext passt: bestehende Infrastruktur, Kompetenzen Ihres Teams, langfristige Pläne. Eine Firma, die ihre Lieblingstechnologie ohne Analyse Ihrer Bedürfnisse durchdrückt, löst ihr Problem, nicht Ihres.
Fragen Sie: warum würden Sie Technologie X für mein Projekt wählen? Die Antwort „weil wir darin am besten sind” ist Ausstieg aus dem Spiel. Die richtige enthält eine Analyse Ihrer Anforderungen, Einschränkungen und Entwicklungspläne.
9. Kulturelle Passung
Die Organisationskultur eines Software House beeinflusst jeden Aspekt der Zusammenarbeit. Eine Firma mit „Yes-Man”-Kultur wird Ihnen nie sagen, dass Ihre Idee schlecht ist. Eine Firma mit Ingenieurkultur sagt es und schlägt eine bessere Lösung vor. Suchen Sie Partner, die „Nein” sagen können und es begründen. Das ist der Wert, für den Sie bezahlen.
10. Vertrag — Absicherung, keine Formalität
IP, NDA, Garantien, Kündigungsklauseln, Code-Escrow, SLA für Support nach dem Go-Live. Diese Punkte müssen vor der Unterzeichnung klar sein. Überlassen Sie sie nicht dem Anwalt am Ende. Ein guter Vertrag schützt beide Seiten und definiert Erwartungen. Besonders die Exit-Klausel — was passiert, wenn die Zusammenarbeit nicht funktioniert? Bekommen Sie Quellcode, Dokumentation und Knowledge Transfer?
Welche Fragen sollte man einem Software House vor dem Vertrag stellen?
Der Anbieter sagte, er habe eine Definition of Done. Er zeigte eine Liste in Jira. Niemand hatte sie seit 3 Monaten gelesen. Das ist Cargo Cult. Stellen Sie Fragen, die Praxis überprüfen, nicht Erklärungen: wann haben Sie die DoD zuletzt aktualisiert? Zeigen Sie einen Commit aus dem Code Review, bei dem ein Senior den PR eines Juniors abgelehnt hat. Zeigen Sie einen Produktionsvorfall und das Post-Mortem dazu.
Framework in der Praxis
Bewerten Sie jedes Kriterium auf einer Skala von 1-5. Summe unter 35 — suchen Sie weiter. Ein Kriterium mit der Bewertung 1 ist ein Deal-Breaker, unabhängig von der Summe. Die häufigsten Fehler: das billigste Angebot wählen (Sie zahlen doppelt für die Rettung), die größte Firma wählen (Ihr Projekt ist für sie unbedeutend), auf Basis einer Präsentation wählen (Folien schreiben keinen Code).
Dieses Framework ist ein Diagnosewerkzeug. Sie erkennen rote Flaggen früh — Sie sparen Monate. Sie ignorieren sie, weil das Angebot hübsch ist — Sie bekommen, was Sie verdient haben.
Möchten Sie die Scorecard als PDF/Excel? Tragen Sie sich unten für die Checkliste ein, wir schicken ein editierbares Template mit 10 Kriterien und Feldern, um drei Anbieter nebeneinander zu bewerten. Wenn Sie möchten, dass wir uns selbst gegen dieses Framework bewerten — schreiben Sie es direkt. Geben Sie uns in irgendeinem Kriterium eine 1, sagen wir Ihnen, wie wir das beheben — oder empfehlen einen Mitbewerber, der dort besser ist als wir.
FAQ
Welche 10 Kriterien gelten bei der Auswahl eines Software House? Portfolio (Case Studies mit Misserfolgen), Entwicklungsprozess (Wiederholbarkeit), Team (Senior-Junior-Zusammensetzung, Fluktuation), Kommunikation (Reaktionszeit), Umgang mit Misserfolgen, Rescue Capability, Preistransparenz, technologische Passung, kulturelle Passung, Vertrag (Exit-Klausel).
Wie bewertet man das Portfolio eines Anbieters? 5 Erfolge ohne einen einzigen Misserfolg sind eine rote Flagge. Fordern Sie Kundenkontakt aus einem Projekt mit Problemen. Prüfen Sie Metriken: Zeit, Budget, Scope Creep, Teamretention.
Was sind rote Flaggen bei der Auswahl eines Entwicklungspartners? Kein Prozess („wir passen uns an den Kunden an”), Junior-only-Team, Fluktuation über 25% pro Jahr, eine Zahl ohne Aufschlüsselung, „Yes-Man”-Kultur, Ablehnung von Kontakt zu schwierigen Kunden, fehlende Exit-Klausel im Vertrag.