Software VendorsDedicated TeamCustom Software DevelopmentTech & Software

Team erweitern oder Modul auslagern? Die Build/Partner-Entscheidung für Softwarehersteller

Softwarehersteller haben zwei Wege, Lieferkapazität aufzubauen: externe Entwickler ins Produktteam holen — oder ein definiertes Arbeitspaket komplett an einen Partner geben. Ein praktischer Entscheidungsrahmen mit zwei echten Beispielen.

Foto: Google Gemini · AI-generated

Jeder Softwarehersteller kennt dasselbe Problem: Die Roadmap ist größer als das Team.

Es gibt zwei ehrliche Wege, diese Lücke mit einem Partner zu schließen. Sie können das Team erweitern — externe Entwickler arbeiten in Ihrem Produktteam, in Ihrer Codebasis, nach Ihrer Architektur. Oder Sie können ein Modul auslagern — ein Partner übernimmt ein definiertes Arbeitspaket und liefert es komplett. Beide Modelle funktionieren. Teuer wird es, wenn das falsche Modell auf die falsche Arbeit trifft.

Hier ist der Entscheidungsrahmen, den wir mit Softwareherstellern nutzen — und zwei echte Projekte, die beide Seiten der Grenze zeigen.

Auslagern, was abtrennbar ist

Manche Arbeit hat eine natürliche Grenze: klarer Umfang, eine stabile Schnittstelle zum Rest des Produkts, kein täglicher Abstimmungsbedarf mit Ihrem Team. Solche Arbeit ist ein Kandidat für die vollständige Übergabe.

Zwei Beispiele aus unserer eigenen Arbeit. Der ERP Advisor ist ein Lead-Qualifizierungs-Tool, das wir für ein ERP-Beratungsunternehmen gebaut haben — ein geführter Fragebogen, der eine passende ERP-Empfehlung erzeugt und qualifizierte Interessenten direkt in Beratungstermine bringt. Kommerziell wichtig, aber nicht das Kernprodukt des Anbieters, und es läuft auf einem eigenen Stack. Die komplette Übergabe an einen Partner hat das eigene Team nichts gekostet: kein Kontextwechsel, kein Technologie-Umweg, keine Verzögerung der Roadmap.

Mobile ERP liegt näher am Produkt, zeigt aber dieselbe Grenzlogik. Die Lager-App eines Herstellers musste von Windows CE — einer Plattform am Ende ihres Lebenszyklus — auf Android umziehen und dabei mit Sage 100 exakt so kommunizieren wie zuvor. Die Schnittstelle war die Grenze: Solange die neue App dieselbe Datenschicht nutzt, konnte die gesamte Modernisierung white-label von einem Partner geliefert werden. Das Team des Herstellers musste für einen einmaligen Plattformwechsel keine Android-Spezialisten werden.

Das Muster in beiden Fällen: Abtrennbarer Umfang plus stabile Schnittstelle gleich Auslagerung. Der Partner trägt das Lieferrisiko; Ihr Team baut weiter am Produkt.

Für den Kern: das Team erweitern

Bei Arbeit im Kernprodukt dreht sich die Rechnung um. Laufende Feature-Entwicklung, Weiterentwicklung der Architektur, der Code, für den Ihre Kunden verlängern — diese Arbeit hat keine saubere Grenze, und sie profitiert von Kontext, der über Monate und Jahre wächst. Sie stückweise auszulagern heißt, bei jedem Stück die Wissenstransfer-Steuer zu zahlen.

Für diese Arbeit ist das richtige Modell ein Dedicated Team: externe Entwickler, fest eingebettet als Erweiterung Ihrer eigenen Engineering-Organisation — Ihr Backlog, Ihre Architekturentscheidungen, Ihre Standards, deren Kapazität. Der Wert wächst gerade deshalb, weil die Menschen bleiben: Ein Entwickler, der achtzehn Monate in Ihrer Codebasis arbeitet, trifft Entscheidungen, die ein rotierender Contractor nicht treffen kann.

Die vier Fragen

Wenn ein Softwarehersteller uns fragt, welches Modell passt, fragen wir vier Dinge zurück:

  • Ist der Umfang abtrennbar? Lässt sich eine Linie ziehen und die Schnittstelle definieren? Wenn ja, ist Auslagerung möglich.
  • Ist es Ihr Kernprodukt? Arbeit, für die Ihre Kunden direkt verlängern, gehört nah an Ihr eigenes Team — erweitern, nicht auslagern.
  • Ist die Arbeit begrenzt oder dauerhaft? Eine Migration oder ein eigenständiges Tool endet; Kernentwicklung nicht. Begrenzt spricht für Auslagerung, dauerhaft für ein eingebettetes Team.
  • Passt die Arbeit zu Ihrem Stack? Ein einmaliger Ausflug in eine fremde Technologie ist ein starkes Auslagerungssignal — diese Expertise für ein einzelnes Projekt intern aufzubauen, rechnet sich selten.

Meist zeigen zwei der Antworten in dieselbe Richtung. Wenn sie sich widersprechen, gewinnt die Kernprodukt-Frage: Den Kern nah halten, die Ränder auslagern.

Wir arbeiten mit Softwareherstellern in beiden Modellen — oft in beiden gleichzeitig für denselben Kunden. Wenn Ihre Roadmap größer ist als Ihr Team: Erzählen Sie uns, was darauf steht — wir sagen Ihnen ehrlich, welche Teile sich auslagern lassen und welche nicht.