Softwareentwicklung auslagern: Nearshoring ohne Fallstricke

Wenn ein Angebot aus Osteuropa mit einem Stundensatz hereinkommt, der halb so hoch ist wie der eines Entwicklers in Linz, sieht die Rechnung auf den ersten Blick einfach aus. Softwareentwicklung auslagern spart Geld, oder? In der Praxis ist das die falsche Frage. Die richtige lautet: Was kostet es dich wirklich, wenn du den Stundensatz um alles ergänzt, was auf der Rechnung nicht steht. Dieser Artikel geht ehrlich durch die Vor- und Nachteile, die versteckten Kosten und die Warnsignale, damit du eine Entscheidung triffst, die du in einem Jahr nicht bereust.

Warum der Stundensatz die schlechteste Kennzahl ist

Ein niedriger Stundensatz vergleicht zwei Dinge, die nicht vergleichbar sind. Ein interner Entwickler kennt dein Produkt, deine Kunden und deine Altlasten. Ein externes Team startet bei null. Der Preisunterschied gleicht sich schneller aus, als die meisten glauben, weil auf beiden Seiten Aufwand entsteht, der auf keiner Rechnung erscheint.

Rechne ehrlich mit: die Zeit, die deine eigenen Leute in die Einarbeitung stecken. Die Meetings zur Abstimmung, die es ohne Auslagerung nicht gäbe. Die Nacharbeit an Code, der zwar die Anforderung erfüllt, aber nicht das, was du eigentlich gemeint hast. Diese drei Posten (Einarbeitung, Koordination, Nacharbeit) sind die eigentlichen Kosten beim Auslagern. Sie stehen nirgends, aber sie sind da.

Eine grobe Faustregel aus der Praxis: Bei einem gut geführten externen Team rechnest du mit einem Overhead von zwanzig bis dreißig Prozent gegenüber der reinen Entwicklungszeit. Bei einem schlecht geführten kann sich der Aufwand verdoppeln, und dann war der günstige Stundensatz das teuerste Angebot im Feld.

Was Auslagern gut kann und was nicht

Auslagern funktioniert dort am besten, wo die Anforderung klar ist und das Wissen darüber gut übertragbar. Eine abgegrenzte Komponente, eine Schnittstelle zu einem bekannten System, eine Migration mit sauberer Spezifikation: Das lässt sich sinnvoll vergeben. Auch für Kapazitätsspitzen ist ein externer Partner gut geeignet, wenn du kurzfristig mehr Hände brauchst, ohne dauerhaft Personal aufzubauen.

Schwierig wird es überall dort, wo das Produkt noch nicht steht. Wenn du selbst noch nicht weißt, wohin die Reise geht, wenn sich Anforderungen wöchentlich ändern, wenn tiefes Verständnis für den Markt und die Nutzer nötig ist, dann ist ein externes Team der falsche Ort für dieses Wissen. Dein Kernprodukt, der Teil, der dich von Wettbewerbern unterscheidet, gehört in der Regel nach innen. Die Randbereiche kann man abgeben.

Ich sage das nicht als Dogma. Es gibt Startups, die mit einem starken Nearshoring-Partner ihr gesamtes Produkt gebaut haben. Aber die hatten dann intern jemanden, der technisch führen konnte. Ohne diese Person wird das Auslagern zum Blindflug.

Nearshoring in CEE: die praktischen Unterschiede

Nearshoring meint in Österreich meist Teams in Mittel- und Osteuropa, also Polen, Tschechien, Rumänien, die Slowakei oder die Ukraine. Der Vorteil gegenüber Offshoring nach Asien ist handfest: gleiche oder benachbarte Zeitzone, kulturelle Nähe, oft sehr gutes Deutsch oder zumindest verlässliches Englisch, und ein Rechtsrahmen innerhalb der EU, der Verträge einfacher macht.

Die Zeitzone klingt banal, ist aber der Unterschied zwischen einer Antwort am Nachmittag und einer Antwort am nächsten Tag. Bei einem Team in derselben Arbeitszeit kannst du Fragen im laufenden Betrieb klären. Bei acht Stunden Zeitverschiebung dauert jede Rückfrage einen ganzen Arbeitstag, und aus einem kleinen Missverständnis wird eine Woche verlorene Arbeit.

Innerhalb der EU hast du außerdem einen berechenbaren Rahmen für Datenschutz und Vertragsrecht. Das ist kein Detail, wenn personenbezogene Daten im Spiel sind. Ein Partner außerhalb der EU verlangt zusätzliche vertragliche Konstruktionen, damit du DSGVO-konform bleibst.

Der Vertrag: wem gehört der Code

Hier machen die meisten den teuersten Fehler, und zwar leise, weil er erst Jahre später auffällt. Ohne ausdrückliche Regelung ist keineswegs klar, dass dir der bezahlte Code auch gehört. Nach österreichischem und deutschem Urheberrecht bleiben die Rechte im Zweifel beim Ersteller. Du zahlst, aber die Nutzungsrechte müssen vertraglich ausdrücklich und vollständig auf dich übergehen.

Achte im Vertrag auf drei Dinge. Erstens die vollständige und unwiderrufliche Übertragung aller Nutzungsrechte am erstellten Code an dich, inklusive dem Recht, ihn zu ändern und weiterzugeben. Zweitens eine klare Regelung zu eingesetzten Fremdbibliotheken und deren Lizenzen, damit du dir nicht ungewollt eine Open-Source-Verpflichtung ins Produkt holst. Drittens eine Vertraulichkeitsvereinbarung, die auch dann noch gilt, wenn die Zusammenarbeit endet.

Regle außerdem, was beim Ende der Zusammenarbeit passiert. Wer übergibt den Quellcode, die Zugänge, die Dokumentation? Ein Partner, der beim Thema Übergabe zögert, sagt dir damit mehr, als ihm lieb ist.

Warnsignale, bevor du unterschreibst

Manche Anbieter erkennst du an dem, was sie tun, bevor überhaupt Code entsteht. Ein Team, das im Erstgespräch keine kritischen Rückfragen zu deiner Anforderung stellt, sondern nur nickt und einen Preis nennt, hat entweder nicht zugehört oder rechnet damit, später nachzuverhandeln. Gute Entwickler stellen unbequeme Fragen.

Weitere Alarmzeichen: ein Festpreis für ein Vorhaben, das noch gar nicht klar spezifiziert ist. Referenzen, mit denen du nicht direkt sprechen darfst. Ein einziger Ansprechpartner, hinter dem eine anonyme Wolke von wechselnden Entwicklern steht. Und die klassische Falle, dass dir im Verkaufsgespräch die Senior-Leute vorgestellt werden, die Arbeit später aber Juniorprofile machen. Frag konkret, wer tatsächlich an deinem Projekt sitzt.

Wie du einen Partner auswählst und steuerst

Teste klein, bevor du groß vergibst. Ein bezahltes Pilotprojekt über zwei oder drei Wochen sagt dir mehr als jedes Angebot. Du siehst, wie das Team kommuniziert, wie sauber es arbeitet und ob die geschätzte Zeit zur tatsächlichen passt. Das kostet ein paar Tausend Euro und erspart dir möglicherweise ein gescheitertes Projekt über sechs Monate.

Beim Steuern gilt: Auslagern heißt nicht abgeben und wegsehen. Du brauchst auf deiner Seite jemanden, der die Anforderungen klar formuliert, das Ergebnis fachlich prüft und Entscheidungen zeitnah trifft. Definiere von Anfang an, was gute Arbeit bedeutet, also Code Reviews, Tests, eine funktionierende Übergabe. Wenn niemand bei dir das beurteilen kann, hol dir diese Rolle dazu, sei es intern oder über ein /cto-sparring, das dir den technischen Rücken freihält.

Arbeite in kurzen Zyklen mit sichtbaren Zwischenergebnissen statt auf ein großes Endergebnis in vielen Monaten hinzuarbeiten. So merkst du früh, wenn etwas in die falsche Richtung läuft, und die Korrektur bleibt billig.

Wann es teurer wird als gedacht

Auslagern wird immer dann teuer, wenn du das interne Verständnis für dein eigenes Produkt verlierst. Wenn niemand mehr weiß, wie die Software funktioniert, machst du dich abhängig, und Abhängigkeit ist der teuerste Zustand in einer Geschäftsbeziehung. Der Partner weiß das auch.

Teuer wird es auch, wenn du auslagerst, um ein Problem zu umgehen, das du eigentlich lösen müsstest: unklare Anforderungen, fehlende technische Führung, ein Produkt ohne Richtung. Diese Probleme wandern mit dem Code über die Grenze und kommen als höhere Rechnung zurück.

Softwareentwicklung auslagern ist ein gutes Werkzeug, wenn du weißt, was du willst, und jemanden hast, der die Qualität beurteilen kann. Es ist ein schlechtes Werkzeug, um Klarheit zu ersetzen, die du selbst noch nicht hast.

Wenn du vor dieser Entscheidung stehst und eine ehrliche zweite Meinung willst, bevor du einen Vertrag unterschreibst, dann lass uns in einem kostenlosen Erstgespräch draufschauen. Melde dich über /kontakt, und wir klären in einer halben Stunde, ob Auslagern in deinem Fall die richtige Wahl ist.