Softwareentwicklungspartner für eine Enterprise-App bewerten
Die Wahl eines Dienstleisters für eine Enterprise-App sieht meist nach einem Vergleich von Präsentationen aus, endet aber als Vergleich von Rechnungen. Das Problem: Die entscheidenden Faktoren tauchen fast nie in den Folien auf; sie zeigen sich im dritten Monat, wenn jede Änderung bereits teuer ist. Schauen wir uns an, welche Fragen du vor der Unterschrift stellen solltest und was du neben Portfolio und Stundensatz prüfen musst.
Ein Portfolio beantwortet die falsche Frage
Fallstudien zeigen, wozu ein Team vor einem Jahr in der Lage war, und verraten fast nichts darüber, wer am Ende an deinem Projekt arbeitet. Teams werden umbesetzt, starke Entwickler wechseln zu anderen Aufträgen, und eine beeindruckende Fallstudie wurde womöglich von Leuten umgesetzt, die gar nicht mehr im Unternehmen sind. Die Frage „Wer genau arbeitet an unserem Projekt mit, und was haben diese Leute vorher gebaut?“ bringt mehr als „Was habt ihr schon gemacht?“
Dasselbe Prinzip gilt für KI-Versprechen. Wenn sich ein Anbieter als KI-gestütztes Softwareentwicklungsunternehmen bezeichnet, lass dir genau aufschlüsseln, was das Modell übernimmt und was bei den Entwicklern bleibt. Da diese Formulierung derzeit auf jeder zweiten Landingpage steht, sortiert schon eine konkrete Antwort die Hälfte der Kandidaten aus.
Eine weitere ehrliche Bitte: Frag nach den Kontakten von zwei Kunden, deren Projekt in Schwierigkeiten geraten ist. Ein gesundes Unternehmen gibt sie heraus, denn interessant ist nicht das ideale Projekt, sondern wie sich der Anbieter verhalten hat, als etwas aus dem Ruder lief.
Ein eigenes Signal ist die Bereitschaft, den echten Prozess zu zeigen: Task-Boards, die Regelmäßigkeit der Builds und die Reporting-Formate. Der Vertrieb zeigt polierte Folien, ein Engineering-Unternehmen führt das Werkzeug vor, mit dem tatsächlich gearbeitet wird.
Das Vertragsmodell zählt mehr als der Stundensatz
Der Stundensatz ist das sichtbarste und zugleich nutzloseste Vergleichskriterium. Eine günstige Stunde mit schlecht definiertem Scope kommt teurer als eine teure Stunde mit klarem Scope, und das zeigt sich schon im zweiten Sprint. Bewerten solltest du, wie der Vertrag aufgebaut ist, nicht die Zahl auf der Preisliste.
Auf dem Markt gibt es fünf Hauptmodelle, und jedes hat eine bestimmte Stelle, an der es scheitert.
| Modell | Passt, wenn | Hauptrisiko |
|---|---|---|
| Festpreis | Der Scope schriftlich festgehalten und stabil ist | Jede Änderung wird zur Verhandlung |
| Time and Materials | Der Scope sich während der Umsetzung verschieben wird | Die Ausgaben wachsen ohne feste Obergrenze |
| Dedicated Team | Die Arbeit ein Jahr oder länger weiterläuft | Leerlauf, wenn die Roadmap ins Stocken gerät |
| Staff Augmentation | Deine eigenen Manager das Projekt führen | Die Qualität hängt von deinem Prozess ab, nicht von ihrem |
| Ergebnisbasiert | Die Deliverables messbar sind | Schwer festzulegen, was als erledigt gilt |
Ein Enterprise-Projekt läuft fast immer auf einem hybriden Modell: Festpreis für ein erstes Modul mit klarem Scope, danach ein Dedicated Team. Entscheidend ist dabei, den Übergang zwischen den Modellen vorab festzulegen; sonst wird der Formatwechsel zu einem neuen Verkaufsgespräch.
Umgekehrt ist auch ein übermäßig flexibler Vertrag ohne feste Zusagen ein Warnsignal. Fehlen in den Unterlagen Zeitpläne oder Abnahmekriterien, gibt es später nichts, woran sich eine Diskussion festmachen lässt.
Kläre außerdem, wie Management- und QA-Zeit abgerechnet werden. In manchen Verträgen ist sie im Entwicklersatz enthalten, in anderen steht sie als eigene Position auf der Rechnung, und bei einem sechsköpfigen Team macht das einen spürbaren Unterschied.
Wer verantwortlich ist, wenn ein Teil des Codes von einem Modell stammt
KI in der Softwareentwicklung ist längst kein Alleinstellungsmerkmal mehr; fast alle setzen sie ein. Der Unterschied liegt heute darin, wie klar ein Anbieter die Grenzen zieht: wo das Modell generiert, wo die Entwickler prüfen und wer die Architekturentscheidung abzeichnet.
Acropolium liefert ein Beispiel für eine klare Abgrenzung: Das Modell übernimmt Boilerplate-Code, die Analyse von undokumentiertem Legacy-Code, das Generieren von Tests und das Aktualisieren der Dokumentation, während Architektur, Geschäftslogik und die Verantwortung für Entscheidungen bei den Entwicklern bleiben. Die Formulierung ist durch und durch nüchtern, lässt sich aber in einem konkreten Sprint überprüfen.
Die zweite Pflichtfrage lautet: Wohin wandert dein Code? Enterprise-Setups werden auf privaten oder lokalen Modellen mit eingeschränktem Zugriff aufgebaut, was bei Acropolium eine eigene Projektphase ist: Die Tools werden passend zu den bestehenden Repositorys ausgewählt, und die Zugriffsregeln stehen vor dem ersten Commit fest. Antwortet ein Dienstleister auf diese Frage mit allgemeinen Aussagen über Sicherheit, kannst du das Gespräch an dieser Stelle beenden.
Lass dir außerdem zeigen, wie der Effekt gemessen wird. Liefergeschwindigkeit, Fehleranzahl und Testabdeckung sind drei Kennzahlen, die vor Beginn und nach Abschluss der Arbeit erfasst werden; ohne sie bleibt jede Beschleunigung ein leeres Versprechen.
Der Papierkram, an den man zuletzt denkt
Der juristische Teil wirkt wie eine Formalität, bis zu dem Moment, in dem man sich trennt. Genau dann wird geklärt, wem der Code gehört, wie Fehler nach der Auslieferung behandelt werden und was die Übergabe an ein anderes Team kostet.
Zu den Grundklauseln, die du vor der Unterschrift im Vertrag sehen solltest, gehören:
- Übertragung des Quellcodes und der Rechte am geistigen Eigentum an den Auftraggeber;
- Eine Geheimhaltungsvereinbarung, unterzeichnet, bevor Details besprochen werden;
- Eine Gewährleistungsfrist nach dem Release mit kostenloser Fehlerbehebung;
- Ein Offboarding-Verfahren und ein Prozess für die Übergabe der Dokumentation.
Eine Gewährleistung nach der Auslieferung ist ein starkes Vertrauenssignal. Eine Firma, die bereit ist, Fehler mehrere Monate lang kostenlos zu beheben, testet in der Regel anders als eine, deren Support mit einer neuen Rechnung beginnt.
Eine Offboarding-Klausel klingt zwar nach Misstrauen, spart aber am meisten Geld. Ein Projekt, aus dem du nicht aussteigen kannst, ohne Code und internes Wissen zu verlieren, kostet mehr als jeder Stundensatz. So oder so: All diese Punkte werden vor der Unterschrift verhandelt und danach kaum noch besprochen.
So sieht ein schneller Check aus
Nimm die konkrete Teamzusammensetzung, das Vertragsmodell, die Verantwortungsgrenzen beim Einsatz von KI und die Ausstiegsbedingungen zusammen; das reicht, um in zwei Meetings die meisten ungeeigneten Optionen auszusortieren. Alles andere lässt sich nur in der Umsetzung prüfen, deshalb sollte ein erster Block klein und messbar bleiben. Die Auswahl eines Anbieters ist also kein Vergleich von Präsentationen, sondern ein Test, wie klar jemand unbequeme Fragen beantwortet.
