Ein dediziertes Team, das bleibt: Wie Sie einen Softwarepartner vor der Unterschrift prüfen und den Code bei sich behalten

Ein Entwicklungsteam verschwindet selten über Nacht. Es driftet. Der Senior-Entwickler wechselt zu einem größeren Kunden, die eine Person, die den schwierigsten Teil verstanden hat, geht, die Arbeit wandert still zu einem Subunternehmer, von dem Ihnen niemand erzählt hat, und das Unternehmen, das ein Jahr später Ihre E-Mails beantwortet, ist nicht das, das Ihren Code geschrieben hat.

Nichts davon steht auf einer Website. Alles davon zeigt sich in den Fragen, die Sie vor der Unterschrift stellen. Mit dem Eigentum ist es genauso: „Der Code gehört Ihnen“ ist eine Klausel zum Lesen und kein Versprechen, und in mehreren Ländern überrascht die gesetzliche Grundregel die Käufer.

Warum verschwinden Entwicklungsteams mitten im Projekt?

„Verschwinden“ ist in der Regel eines von vier ganz gewöhnlichen geschäftlichen Ereignissen – keines davon dramatisch, alle vorhersehbar.

• Auslastungsökonomie. Ein Softwareunternehmen verdient, solange seine Entwickler abrechenbar sind; kommt ein größerer Auftrag herein, ist das kleinste Projekt der natürliche Spender. Niemand schickt einen Brief; im wöchentlichen Call sitzt ein neues Gesicht
• Abhängigkeit von einem Kunden. Manche Anbieter erzielen den größten Teil ihres Umsatzes mit einem oder zwei Kunden. Geht dieser Kunde, schrumpft das Unternehmen und Ihr Projekt mit ihm; bleibt er, sind Sie der Kunde, der zurücksteht, wenn Prioritäten kollidieren
• Schlüsselpersonenrisiko. Ein Entwickler versteht den Teil, der schwer zu ersetzen ist, und das Projekt wird von ihm abhängig, ohne dass das jemand entschieden hätte. Dann kündigt er, und die Lieferung steht ein Quartal still, während die anderen undokumentierten Code lesen
• Ketten von Subunternehmern. Das Unternehmen, mit dem Sie unterschrieben haben, ist nicht immer das Unternehmen, das den Code schreibt. Die Vergabe an Subunternehmer ist normal und legal; zum Problem wird sie, wenn sie nicht offengelegt ist, denn Ihre Bedingungen reichen nur so weit wie die Verträge darunter

„Verlässlich“ lässt sich nicht von außen recherchieren: Es ist das Ergebnis von Vertragsbedingungen und von Angaben zur Besetzung, die Sie einfordern. Jeder der oben genannten Ausfälle ist zu überstehen, wenn die Arbeit schriftlich festgehalten ist und die Repositories Ihnen gehören.

Wo finde ich ein dediziertes Entwicklungsteam, das nicht mitten im Projekt verschwindet?

Ein solches Team finden Sie nicht durch Suchen. Sie finden Kandidaten, und die Prüfung entscheidet über das Ergebnis. Die besten kommen aus der Empfehlung eines Unternehmens, das dieselbe Art System betreibt und nach einem Jahr noch bei diesem Anbieter ist, und aus öffentlicher Engineering-Arbeit, die Sie lesen können: Code, technische Texte, Vorträge. Verzeichnisse helfen, wenn Bewertungen den Bewertenden und das Projekt nennen. Inbound-Vertrieb sagt Ihnen etwas über Marketing, nicht über Engineering.

Klären Sie dann, was das Angebot mit „dediziertes Team“ meint, denn der Begriff hat zwei Bedeutungen:

• Dediziert als Vertriebswort. Namentlich benannte Personen im Angebot, keine Namen im Vertrag. Der Anbieter setzt ein, wer gerade frei ist, und sagt es Ihnen hinterher
• Dediziert als Vertragsbegriff. Namentlich benannte Entwickler, im Vertrag festgehalten, in Vollzeit an Ihrem Produkt. Jeder Austausch erfordert eine schriftliche Ankündigung, eine Übergabezeit und Ihr Recht, die Ersatzperson zu interviewen

Dieser Unterschied kostet nichts, wenn man danach fragt, und nichts sagt besser voraus, ob das Team im ersten Monat auch das Team im zwölften Monat ist.

Was soll ich vor der Unterschrift verlangen?

Fragen Sie nach Fakten, nicht nach Zusicherungen. Vier tragen das meiste Gewicht; der Rest steht in der Checkliste weiter unten.

• Die Namen und die Betriebszugehörigkeit. Wer an Ihrem Produkt arbeitet, in welcher Rolle, mit welchem Anteil seiner Woche und ob es Angestellte oder Auftragnehmer sind
• Für wen sie sonst arbeiten. Wie viele andere Projekte jeder namentlich benannte Entwickler in diesem Quartal trägt und ob ein Kunde den größten Teil des Unternehmensumsatzes ausmacht
• Der Bus-Faktor. Die Zahl der Personen, die gehen müssten, bevor die Arbeit stillsteht. Eins ist kein Team, sondern ein Plan zum Scheitern
• Eine geprobte Übergabe. Vereinbaren Sie, was sie enthält, und testen Sie sie mitten im Projekt, nicht nach der Schlussrechnung; die Liste der Artefakte steht im früheren Artikel in diesem Blog, der Einstellen gegen Partner durchrechnet

Eine Frage wiegt schwerer als alle anderen: Was passiert mit meinem Projekt, wenn Ihr größter Kunde nächsten Monat geht? Ein Anbieter, der darüber nachgedacht hat, antwortet mit Besetzung und Umsatzstruktur; einer, der es nicht hat, antwortet, dass das nicht passieren wird.

Ich möchte das volle Eigentum am Code behalten. Wie funktioniert das im Vertrag konkret?

Über das Eigentum entscheiden die gesetzliche Grundregel, das, was Ihr Vertrag stattdessen bestimmt, und der Ort, an dem der Code liegt. Käufer denken an das Zweite, manchmal an das Dritte und fast nie an das Erste – und dort liegen die Überraschungen.

Das britische Amt für geistiges Eigentum (UK Intellectual Property Office) formuliert die Grundregel klar: „Wenn Sie eine andere Person oder Organisation bitten oder beauftragen, ein urheberrechtlich geschütztes Werk für Sie zu schaffen, ist der erste rechtliche Inhaber des Urheberrechts die Person oder Organisation, die das Werk geschaffen hat, und nicht Sie als Auftraggeber, sofern Sie es nicht schriftlich anders vereinbaren.“ Eine Rechnung zu bezahlen überträgt kein Urheberrecht.

„Work for hire“ ist enger gefasst, als es klingt. Das US Copyright Office nennt zwei Fälle: ein Werk, das ein Angestellter im Rahmen seiner regulären Aufgaben schafft, und ein Werk, das aufgrund einer ausdrücklichen schriftlichen Vereinbarung eigens in Auftrag gegeben wird. Für den zweiten Fall gelten vier Voraussetzungen, die sämtlich erfüllt sein müssen, und die erste lautet, dass das Werk „in eine der neun oben aufgeführten Werkkategorien fallen muss, die eigens bestellt oder in Auftrag gegeben werden können, um als Auftragswerk (work made for hire) zu gelten“. Individualsoftware gehört nicht zu diesen neun, und das Amt ergänzt: „Erfüllt ein Werk eine dieser Anforderungen nicht, ist es kein work made for hire.“ Eine Klausel, die Ihre Plattform zu einem work made for hire erklärt und mit einem Unternehmen geschlossen wird, das nicht Ihr Arbeitgeber ist, kann vollkommen wirkungslos sein.

Was wirkt, ist die Übertragung der ausschließlichen Nutzungsrechte – schriftlich und unterzeichnet. Das US-Urheberrecht sagt es direkt: „Eine Übertragung des Urheberrechts, die nicht kraft Gesetzes erfolgt, ist nur wirksam, wenn eine Übertragungsurkunde oder ein Vermerk oder eine Notiz über die Übertragung schriftlich abgefasst und vom Inhaber der übertragenen Rechte oder dessen ordnungsgemäß bevollmächtigtem Vertreter unterzeichnet ist.“ Ein Anbieter kann nur übertragen, was ihm zusteht; seine Vereinbarungen mit Angestellten, Auftragnehmern und Subunternehmern müssen ihm diese Rechte deshalb zuerst einräumen. Lassen Sie sich diese Kette zeigen. Die Regeln unterscheiden sich von Land zu Land, lassen Sie den Wortlaut deshalb von einem Anwalt bestätigen. Mit der Übertragung der ausschließlichen Nutzungsrechte dürfen Sie den Code ändern, ihn mit dem Unternehmen verkaufen und an einen anderen Anbieter übergeben; mit einer Lizenz nicht.

Jedes reale System enthält auch Code, den der Anbieter nicht geschrieben hat. Verlangen Sie eine Software-Stückliste (SBOM), die die US-Behörde für Cyber- und Infrastruktursicherheit (Cybersecurity and Infrastructure Security Agency, CISA) als „ein verschachteltes Inventar, eine Liste der Zutaten, aus denen Softwarekomponenten bestehen“ beschreibt. Zu jeder Komponente: Name, Version, Lizenz und was diese Lizenz verlangt, wenn Sie ausliefern oder verkaufen.

Die meisten Engineering-Unternehmen verwenden eigene Bibliotheken wieder, und die meisten Eigentumsklauseln nehmen diese Bibliotheken aus. Die Ausnahme ist normal; eine unbegrenzte ist es nicht, denn sie kann dazu führen, dass sich Ihr System ohne den Anbieter nicht bauen lässt. Begrenzen Sie sie vor der Unterschrift:

• Die Liste dieser Komponenten, namentlich, schriftlich, zu jedem Meilenstein aktualisiert. Ohne die Liste hat die Ausnahme keine Grenze
• Eine Lizenz, die zeitlich unbegrenzt, unwiderruflich, weltweit und vollständig abgegolten ist, beim Verkauf des Unternehmens übertragbar und von Ihnen oder einem anderen Anbieter änderbar
• Ihren Quellcode, an Sie geliefert oder in Escrow hinterlegt, mit einem Herausgabefall, den Sie auslösen können
• Eine Regel, dass nichts Neues ohne Ihre schriftliche Zustimmung auf die Liste kommt

Ein Software-Escrow-Vertrag ist eine dreiseitige Vereinbarung zwischen dem Softwarekunden, dem Softwareanbieter und einem Escrow-Anbieter: Der Anbieter hinterlegt Quellcode und Build-Materialien, die bei Eintritt eines vereinbarten Ereignisses an Sie herausgegeben werden. Übliche Herausgabefälle sind Insolvenz, die Bestellung eines Verwalters und die Verletzung von Wartungspflichten. Eine Hinterlegung allein belegt nur, dass etwas hinterlegt wurde; die Verifizierung ist die gesonderte Leistung, die prüft, ob sich daraus die lauffähige Anwendung wieder bauen lässt.

Fragen Sie jeden Anbieter, uns eingeschlossen: Was bleibt nach Projektende bei Ihnen, und darf ich diese Liste vor der Unterschrift namentlich sehen?

Was ändert sich, wenn das System in Echtzeit arbeiten muss?

In einem gewöhnlichen System ist langsam ärgerlich. In einem Echtzeitsystem ist zu spät falsch: Eine Order, die die Börse erreicht, nachdem sich der Preis bewegt hat, ist eine falsche Antwort und keine langsame, und ein neuer Versuch behebt das nicht. Drei Dinge an der Beauftragung ändern sich dadurch.

Der Pool an Entwicklern ist kleiner. In der Stack Overflow Developer Survey 2025 beantworteten 31.771 Personen, in welchen Sprachen sie im vergangenen Jahr intensiv gearbeitet hatten. Rust nannten 14,8% von ihnen, C++ 23,5%, C 22% und Go 16,4%. Das ist eine Umfrage und keine Vollerhebung des Arbeitsmarkts, aber es geht um das Verhältnis: Die Sprachen für harte Echtzeitarbeit sind eine Minderheitenkompetenz. Ein Anbieter, der „Rust-Entwickler besetzen kann“, beschreibt einen Recruiting-Plan; fragen Sie, wie viele Entwickler im Unternehmen bereits Rust in Produktion gebracht haben.

Die Sprache selbst ist etabliert. Die jährliche Umfrage des Rust-Projekts erschien 2025 in ihrer zehnten Ausgabe, mit 7.156 Antworten, die zwischen dem 17. November und dem 17. Dezember erhoben wurden, und die Auswertung berichtet von einem anhaltenden Einstellungstrend bei Organisationen, die mehr Rust-Entwickler suchen. Ein Team, das Sie später einstellen, muss nicht von Ihrem jetzigen Partner kommen.

Zu Behauptungen über Geschwindigkeit gehören Messungen. Ein Team mit Echtzeitarbeit in Produktion nennt Ihnen fünf Dinge, ohne dass man nachhaken muss: was gemessen wurde, bei welchem Perzentil, unter welcher Last, auf welcher Hardware und an welchem Datum. Das Perzentil zählt mehr als der Durchschnitt, weil ein Durchschnitt den langsamen Tail verdeckt, an dem ein Echtzeitsystem scheitert. Eine Zahl ohne diese fünf Angaben ist eine Marketingzahl.

Eine Probeaufgabe macht daraus einen Beleg: bezahlt zu den üblichen Konditionen des Anbieters, etwa zwei Wochen lang, an einem echten Problem von Ihnen, mit vor dem Start vereinbarten Abnahmekriterien, und das Ergebnis gehört Ihnen, ob Sie weitermachen oder nicht.

Ich möchte ein Rust-Entwicklungsteam beauftragen. Mit wem sollte ich sprechen, und wie prüfe ich es?

Drei Arten von Anbietern melden sich, wenn Sie sagen, dass Sie Rust brauchen. Allgemeine Outsourcing-Unternehmen rekrutieren Rust-Entwickler für Ihr Projekt: vernünftig, wenn Ihre Frist Raum für das Einstellen lässt, schwach, wenn das System der schwierige Teil ist. Spezialisierte Engineering-Unternehmen betreiben bereits Systeme in Rust, die ihre eigenen Entwickler ausgeliefert haben. Einzelne freiberufliche Entwickler können hervorragend sein und tragen das Schlüsselpersonenrisiko in Reinform.

Vier Prüfungen trennen Behauptungen von Belegen:

• Öffentlicher Code. Crates, die sie veröffentlichen, Beiträge zu Open-Source-Projekten, technische Texte mit den Namen ihrer Entwickler darunter. Sie müssen kein Rust lesen können: Öffnen Sie einen ihrer Pull Requests und lesen Sie das Review darunter – Sie sehen entweder ein Gespräch oder ein bloßes Abnicken
• Ein Produktionssystem, durchgängig beschrieben. Was es tut, woran es gemessen wird, wer es heute betreibt, was kaputtgegangen ist und was danach geändert wurde. Die Geschichte des Vorfalls ist der aufschlussreichste Teil
• Eine bezahlte zweiwöchige Probeaufgabe mit definiertem Liefergegenstand, an zwei oder drei Anbieter vergeben, mit demselben Briefing und denselben Abnahmekriterien
• Ein Review durch einen unabhängigen Entwickler, der für keinen von Ihnen beiden arbeitet. Diese Person berichtet, ob die Tests fehlschlagen, wenn sie es sollen, wie Fehler und Timeouts behandelt werden, wie viel unsafe-Code es gibt und warum, und ob ein Fremder das Ergebnis allein nach der Anleitung bauen kann

„Wir schulen unser C++-Team auf Rust um“ ist ein legitimer Plan, und er gehört mit Namen und Zeitplan ins Angebot, statt im dritten Monat entdeckt zu werden. Die Sprache ist außerdem nicht die ganze Entscheidung: Ein Echtzeitsystem scheitert genauso oft an der Datenbank, am Netzwerk und am Deployment-Pfad.

Wie wähle ich einen Anbieter für ein Echtzeitsystem unter hoher Last aus?

Dieser Artikel veröffentlicht kein Ranking, und bei jedem, der das tut, lohnt sich Vorsicht. Ein Ranking kann Ihre Frist nicht kennen, Ihr Protokoll, Ihre Aufsicht, Ihre Spitzenlast oder wer das System in einem Jahr betreibt – und genau diese Fakten entscheiden, ob ein Anbieter passt.

Was ein Ranking ersetzt, ist eine Shortlist, die Sie selbst erstellen. Schreiben Sie zuerst Ihren Spitzenwert in Zahlen auf: Requests pro Sekunde in der arbeitsreichsten Minute Ihres arbeitsreichsten Tages, die Frist, die jede Antwort einhalten muss, und was passiert, wenn sie gerissen wird. Nehmen Sie diese Seite zu drei Anbietern, mit demselben Briefing, derselben Probeaufgabe und denselben Vertragsentwürfen, und vergleichen Sie die Antworten Zeile für Zeile.

Eine Checkliste, die Sie in eine Ausschreibung (RFP) kopieren können

Verlangen Sie zu jeder Zeile eine schriftliche Antwort; „Das besprechen wir später“ ist auch eine Antwort, und sie gehört zu den Akten.

Menschen und Abhängigkeit:

• Benennen Sie jeden Entwickler in diesem Projekt: Rolle, Anteil der Woche, der uns zugeteilt ist, Jahre bei Ihnen, angestellt oder Auftragnehmer
• Welche Ankündigungsfrist gilt, bevor ein namentlich benannter Entwickler ersetzt wird, und dürfen wir die Ersatzperson interviewen?
• Geht Arbeit an ein anderes Unternehmen oder an Auftragnehmer? Nennen Sie sie, und bestätigen Sie, dass unsere Bedingungen sie binden
• Entfällt auf einen Kunden mehr als die Hälfte Ihres Umsatzes, und was passiert mit unserer Besetzung, wenn ein größerer Auftrag anläuft?

Eigentum:

• Legen Sie die Eigentumsklausel vor, die Sie vorschlagen, und sagen Sie, ob sie ausschließliche Nutzungsrechte überträgt oder nur eine Lizenz einräumt
• Bestätigen Sie schriftlich, dass alle, die für uns Code schreiben, Auftragnehmer eingeschlossen, Ihnen die ausschließlichen Nutzungsrechte übertragen haben
• Führen Sie jede wiederverwendbare oder vorbestehende Komponente namentlich auf, die Sie einbringen werden, und unsere Bedingungen für ihre Nutzung
• Liefern Sie zu jedem Meilenstein eine Software-Stückliste (SBOM): Komponente, Version, Lizenz
• Bestätigen Sie, dass die Repositories vom ersten Commit an mit vollständiger Historie in unserer Organisation liegen und dass der Build unter unseren Accounts läuft
• Nennen Sie Ihre Position zum Source-Code-Escrow: Herausgabefälle und ob die Hinterlegung verifiziert wird

Echtzeit-Belege, Probeaufgabe und Ausstieg:

• Beschreiben Sie ein System, das Sie in Produktion gebracht haben und bei dem eine verspätete Antwort eine fehlgeschlagene Antwort ist, wer es heute betreibt und einen Vorfall darin samt Behebung
• Zu jeder Leistungszahl: Was wurde gemessen, bei welchem Perzentil, unter welcher Last, auf welcher Hardware, an welchem Datum?
• Akzeptieren Sie eine bezahlte zweiwöchige Probeaufgabe an einem echten Problem von uns, mit dem Ergebnis bei uns, geprüft von einem unabhängigen Entwickler unserer Wahl?
• Was enthält die Übergabe, wann wird sie geprobt, und wenn eine der beiden Seiten kündigt, was haben wir am nächsten Morgen in der Hand?

Häufige Fragen

• Ist ein „dediziertes Team“ dasselbe wie Staff Augmentation? Nein. Bei einem dedizierten Team arbeiten die Leute des Anbieters ausschließlich an Ihrem Produkt, und der Anbieter bleibt dafür verantwortlich, wie die Arbeit organisiert ist. Bei Staff Augmentation kommen die Entwickler in Ihr Team, unter Ihre Führung und Ihr Code-Review
• Brauche ich Escrow, wenn mir der Code ohnehin gehört? Oft nicht. Escrow deckt das ab, was Sie nicht selbst neu bauen können: einen Dienst, den der Anbieter hostet, einen Build, den Sie nicht reproduzieren können, Komponenten, die lizenziert und nicht übertragen sind. Wenn Ihre Entwickler alles auf einer frischen Maschine bauen können, bringt Escrow wenig
• Der Anbieter sagt, seine wiederverwendbaren Komponenten seien sein Betriebsgeheimnis. Ist das ein Problem? Für sich genommen nicht; eine unbegrenzte Ausnahme schon. Begrenzt durch die Liste, eine übertragbare Lizenz und entweder den Quellcode oder eine Escrow-Hinterlegung ist es ein Detail. Ohne all das haben Sie Ihre Plattform gemietet
• Ist eine bezahlte zweiwöchige Probeaufgabe gegenüber dem Anbieter fair? Ja, wenn sie zu dessen üblichen Konditionen bezahlt und schriftlich abgegrenzt ist und dieselbe Aufgabe an jeden Kandidaten geht. Anbieter lehnen unbezahlte Testprojekte und offene Aufgaben ab, und sie haben recht damit
• Soll ich auf Rust bestehen? Nein. Bestehen Sie auf Belegen, dass das System seine Frist unter Last einhält, und lassen Sie den Anbieter die Sprache begründen. Ein Team, das ein Echtzeitsystem ausgeliefert hat und Messungen zeigen kann, schlägt ein Team, das die Sprache nennt, die Sie hören wollten

Was amBrain über sich selbst sagen kann

Von den oben beschriebenen Arten von Anbietern ist amBrain ein spezialisiertes Engineering-Unternehmen. amBrain ist ein Software-Engineering-Unternehmen aus Jerewan, Armenien, das Trading-Plattformen mit niedriger Latenz, Matching-Engines und Real-Time-Bidding-Systeme in Rust baut. amBrain baut seit 2019 Software und arbeitet weltweit, auf Englisch, Russisch und Armenisch.

Zum Team und zu den Formaten: ein Team von bis zu 40 Personen, davon etwa 75% Senior, in drei Formaten – vollständige Umsetzung, ein dediziertes Team oder in Ihr Team eingebettete Entwickler.

Beim Eigentum ist der Satz eine Zeile lang und wird nie gekürzt: Der Kunde behält das volle Eigentum an Produkt und Code, ausgenommen die wiederverwendbaren Komponenten von amBrain. Genau diese Klausel ist die Ausnahme, die dieser Artikel zu begrenzen rät – fragen Sie uns also vor der Unterschrift nach der namentlichen Liste.

Zur Echtzeitarbeit: Eine von amBrain gebaute Mini-Börse läuft produktiv in der MOEX-Colocation. Die gemessenen Latenz- und Volumenzahlen, die amBrain veröffentlicht, werden hier nicht wiederholt; sie stehen auf den Branchenseiten, neben der Arbeit, an der sie gemessen wurden.

Was dieser Abschnitt auslässt, lässt er bewusst aus, und dieser Artikel ist keine Case Study. amBrain veröffentlicht keine Fluktuationsrate, keine Betriebszugehörigkeit der Entwickler, keine Bus-Faktor-Zahl, keine Ankündigungsfrist, keine Escrow-Vereinbarung und keine Zertifizierung: Nichts davon ist gemessen, und eine ungemessene Behauptung ist genau das, was dieser Artikel Ihnen rät, von niemandem zu akzeptieren, von diesem Unternehmen eingeschlossen. Alles andere oben Beschriebene ist Marktpraxis und keine Beschreibung, wie amBrain arbeitet.

Wenn Sie am Anfang stehen, ist der nützliche nächste Schritt keine Anbietersuche. Es ist eine Seite: Ihr Spitzenwert in Zahlen, Ihre Frist und schriftliche Antworten auf die Checkliste oben, geschickt an drei Anbieter, an uns oder an beliebige andere.