Offshore oder Nearshore? Entscheidungshilfe für CTOs

Die meisten Gespräche darüber, wo Software gebaut werden soll, beginnen mit einer Zahl: dem Tages- oder Stundensatz. Er ist leicht zu vergleichen, leicht in eine Tabelle einzutragen und leicht gegenüber der Finanzabteilung zu verteidigen. Er ist aber auch einer der schwächsten Prädiktoren dafür, was ein Projekt tatsächlich kosten wird. Dieser Leitfaden richtet sich an CTOs, Engineering-Leiter und Einkaufsverantwortliche in Europa, Nordamerika und am Golf, die zwischen Onshore-, Nearshore- und Offshore-Teams wählen müssen und dies anhand der Gesamtkosten der Lieferung statt der Preisliste tun wollen.

Zu den allgemeinen Argumenten für Remote-Teams lesen Sie unsere Leitfäden zu den Vorteilen von Offshore-Webentwicklung und zu agiler Offshore-Lieferung. Dieser Artikel vergleicht die drei Modelle ehrlich.

Die drei Modelle in einfachen Worten

Onshore

Das Team sitzt in Ihrem eigenen Land, oft in Ihrer Stadt oder Region. Sie teilen Zeitzone, Rechtssystem, Sprache und meist auch die Geschäftskultur. Wenn es darauf ankommt, können Sie alle in einen Raum holen.

Nearshore

Das Team sitzt in einem benachbarten Land mit gleicher oder sehr naher Zeitzone. Für ein Unternehmen in Westeuropa kann das ein anderes europäisches Land bedeuten, für ein Unternehmen in den USA oft Lateinamerika. Sie haben den größten Teil des Arbeitstages gemeinsam und im Bedarfsfall für einen Workshop einen kurzen Flug.

Offshore

Das Team ist weit entfernt, mit großem Zeitzonenunterschied. UnlockLive arbeitet für viele Kunden auf diese Weise: Wir haben einen Hauptsitz in Toronto und ein Engineering-Zentrum in Dhaka. Der Unterschied ist real und prägt, wie Arbeit organisiert wird; deshalb widmet sich der Rest dieses Artikels ihm ausführlich.

Diese Bezeichnungen beschreiben Entfernung und Überschneidung. Über die Kompetenz sagen sie nichts aus. Starke und schwache Teams gibt es in jeder Kategorie, und die Managementqualität eines Anbieters ist meist wichtiger als sein Standort auf der Landkarte.

Was die Gesamtkosten tatsächlich umfassen

Beim Vergleich zweier Angebote ist der Satz der sichtbare Teil. Darunter liegen die folgenden Posten, die sich zwischen Modellen und zwischen Anbietern unterscheiden. Entscheidend ist, dass jeder davon in Ihrer Vergleichstabelle steht.

Koordinations- und Managementaufwand

Jedes externe Team braucht auf Ihrer Seite jemanden, der priorisiert, Fragen beantwortet und Arbeit abnimmt. Entfernung bringt schriftliche Kommunikation, Übergabenotizen und terminierte Calls mit sich. Fragen Sie jeden Anbieter, wer auf seiner Seite die Arbeit im Tagesgeschäft steuert und wie viele Stunden pro Woche er von Ihren Leuten erwartet.

Zeitzonenüberlappung

Die Überlappung ist die Zahl der gemeinsamen Arbeitsstunden. Sie entscheidet, ob eine blockierende Frage in Minuten oder erst am nächsten Morgen beantwortet wird. Weiter unten wird sie ausführlich behandelt, weil Käufer genau diesen Faktor am stärksten unterschätzen.

Nacharbeit

Nacharbeit, verursacht durch unklare Anforderungen und spätes Feedback, ist in den meisten gescheiterten Projekten der größte versteckte Kostenfaktor. Kurze Sprints mit Demos alle ein bis zwei Wochen sind die übliche Gegenmaßnahme.

Einarbeitung

Ein neues Team braucht Zeit, um Ihre Domäne, Codebasis und Werkzeuge kennenzulernen. Planen Sie sie ein; ein Anbieter, der in Woche eins volle Produktivität verspricht, ist optimistisch.

Aufsetzen von IP, Vertrag und Datenschutz

Der rechtliche Aufwand wächst mit jeder weiteren Rechtsordnung: Übertragung von IP, ein Auftragsverarbeitungsvertrag, möglicherweise Mechanismen für grenzüberschreitende Übermittlungen. Das vor der ersten Codezeile zu erledigen ist weit günstiger, als es während eines Streits zu reparieren.

Fluktuation und Kontinuitätsrisiko

Wenn ein Schlüsselentwickler geht, wer kennt dann das System? Fluktuation gibt es in jedem Modell; der Unterschied liegt darin, ob der Anbieter einen Ersatz und einen Übergabeprozess hat.

Zeitzonenüberlappung, ehrlich betrachtet

Überlappung ist Geometrie, und keine Vertriebssprache ändert daran etwas. Hier das allgemeine Bild für die Regionen, an die sich dieser Artikel richtet, ohne exakte Stunden vorzutäuschen, die sich mit der Sommerzeit verschieben.

• Dhaka und Toronto oder die US-Ostküste: Der Unterschied ist groß, etwa ein halber Tag. Die tatsächliche Überlappung ist ein schmales Fenster zu Beginn des nordamerikanischen und am Ende des bangladeschischen Tages, und Teams dehnen meist die Arbeitszeiten einer Seite leicht, damit es funktioniert. Der Großteil der Zusammenarbeit läuft asynchron, mit einem kurzen täglichen Sync.
• Dhaka und Mitteleuropa: ein mittlerer Unterschied. Es gibt eine nutzbare gemeinsame Zeitspanne am europäischen Vormittag und Nachmittag, genug für ein tägliches Stand-up und regelmäßig terminierte Live-Pairing-Sessions, wenn auch nicht für einen vollständigen gemeinsamen Tag.
• Dhaka und der Golf: ein kleiner Unterschied von wenigen Stunden. Die Arbeitstage am Golf und in Bangladesch überlappen über einen guten Teil des Tages, was die Zusammenarbeit in Echtzeit viel einfacher macht als mit Nordamerika.
• Nearshore-Paare (zum Beispiel Westeuropa mit benachbarten Ländern oder Nordamerika mit Lateinamerika) teilen den größten Teil des Tages oder den ganzen Tag.

Arbeit, die gut spezifiziert ist und über Pull Requests und Demos geprüft wird, funktioniert mit einem kurzen Zeitfenster und guter Schriftlichkeit gut. Arbeit, bei der Designer, Product Owner und Entwickler den ganzen Tag gemeinsam entscheiden müssen, nicht.

Ein Entscheidungsrahmen: Projekttyp und passendes Modell

Es gibt kein universell bestes Modell. Diese Tabelle ist ein Ausgangspunkt, kein Urteil, und ein guter Partner passt sie an Ihre Situation an.

Projekttyp	Meist die beste Wahl	Warum
Klar definierter Aufbau mit eindeutigen Spezifikationen und Abnahmekriterien	Offshore oder Nearshore	Kaum Bedarf an ständigen Live-Entscheidungen; schriftliche Spezifikationen und Sprint-Demos tragen die Arbeit.
Produkt, das noch erkundet wird, mit häufigen Kurswechseln	Onshore oder Nearshore für die Discovery, danach jedes Modell	Die Discovery braucht schnellen, bandbreitenstarken Austausch mit den Stakeholdern.
Langlebiges Produkt mit stetigem Backlog	Dediziertes Team, Offshore oder Nearshore	Kontinuität und gemeinsamer Kontext bauen sich über die Zeit auf, und die Einarbeitung wird nur einmal bezahlt.
Modernisierung oder Migration eines Altsystems	Hybrid	Onshore-Architekten und Fachexperten, während ein Remote-Team den Großteil der Umsetzung übernimmt.
KI-Agenten, RAG oder datenintensive Funktionen	Abhängig von der Sensibilität der Daten	Synthetische oder maskierte Daten mit einem Remote-Team verwenden oder den Umgang mit sensiblen Daten in der Region halten.
Stark regulierte Daten oder Sicherheitsanforderungen vor Ort	Onshore oder in der Region mit Kontrollen	Rechtliche, Audit- und Residenzvorgaben können jeden Preisunterschied überwiegen.
Kurzes Projekt mit festem Umfang, etwa eine Marketing-Website oder eine Integration	Beliebig, nach Qualität und Preis gewählt	Der Koordinationsaufwand bleibt klein, weil das Projekt kurz ist.

Viele der am besten geführten Projekte sind hybrid: ein kleiner Onshore-Verantwortlicher für Produkt und Architektur sowie ein größeres Remote-Lieferteam. So strukturieren wir auch viele Projekte, mit einem Projektmanager in Toronto als zentralem Ansprechpartner und Entwicklern in Dhaka, wie auf unserer Seite zur individuellen Softwareentwicklung beschrieben.

Verträge, die Sie schützen

Festpreis im Vergleich zu Time-and-Materials

Ein Festpreis gibt Ihnen Kostensicherheit, wenn der Umfang wirklich klar ist. Seine Schwäche ist die Änderung: Jede neue Idee wird zum Change Request, und Anbieter schützen ihre Marge, indem sie Risiko einpreisen. Am besten funktioniert er bei abgegrenzten Projekten mit freigegebenen Designs und Abnahmekriterien.

Time-and-Materials bietet Flexibilität und Transparenz, und Sie zahlen den tatsächlich geleisteten Aufwand. Seine Schwäche ist, dass die Kosten ohne eigene Disziplin abdriften können. Schützen Sie sich mit einer monatlichen Obergrenze, einem priorisierten Backlog, Sprint-Demos und sichtbaren Zeitberichten.

Ein verbreiteter Mittelweg ist eine kurze, bezahlte Discovery-Phase auf Time-and-Materials-Basis, gefolgt von der Lieferung des in der Discovery entstandenen Umfangs zum Festpreis. Wofür Sie sich auch entscheiden: Die Vertragsform ist weniger wichtig als die Frage, ob beide Seiten schriftlich festgehalten haben, was „fertig“ bedeutet.

Übertragung von IP

Der Vertrag sollte unmissverständlich festhalten, dass Ihnen alles gehört, was für Sie geschaffen wird. Prüfen Sie diese Punkte:

• Übertragung der IP an allen Liefergegenständen auf Ihr Unternehmen, nicht nur eine Lizenz.
• Die eigenen Mitarbeitenden und Subunternehmer des Anbieters haben ihre Rechte zuvor an den Anbieter übertragen.
• Eine klare Liste der verwendeten Open-Source- und Drittanbieter-Komponenten mit ihren Lizenzen.
• Quellcode, Infrastrukturdefinitionen und Dokumentation werden von Tag eins an in Repositories geliefert, die Sie kontrollieren.

Die Regeln unterscheiden sich von Land zu Land; lassen Sie die Formulierung daher von Ihrer eigenen Rechtsberatung prüfen.

Datenverarbeitung und Vertraulichkeit

Wenn der Anbieter mit personenbezogenen Daten in Berührung kommt, benötigen Sie einen Auftragsverarbeitungsvertrag, bevor Zugriff gewährt wird. Er sollte die Unterauftragsverarbeiter benennen, angeben, wo Daten gespeichert sind und von wo aus darauf zugegriffen wird, Sicherheitsmaßnahmen festlegen, die Meldung von Datenschutzverletzungen regeln und sagen, was bei Vertragsende mit den Daten geschieht. Prüfen Sie bei europäischen personenbezogenen Daten den Mechanismus, der eine Übermittlung außerhalb der EU oder des EWR erlaubt. Bei Projekten am Golf müssen Regeln zu Datenresidenz und Datenübermittlung im jeweiligen Land mit lokaler Rechtsberatung geklärt werden, bevor Sie die Architektur entwerfen. Halten Sie, wo möglich, echte personenbezogene Daten ganz aus Entwicklungsumgebungen heraus und verwenden Sie maskierte oder synthetische Daten.

Eine Due-Diligence-Checkliste für jeden Anbieter

Verwenden Sie diese Liste für Onshore-, Nearshore- und Offshore-Anbieter gleichermaßen. Es ist derselbe Fragenkatalog, und die Antworten sind das, was Sie eigentlich einkaufen.

1. Wer wird die Arbeit erledigen? Bitten Sie darum, die tatsächlichen Entwickler und den Leiter kennenzulernen, nicht nur den Vertrieb. Klären Sie, ob die im Angebot genannten Personen auch die zugewiesenen sind.
2. Wie wird Arbeit geplant und gezeigt? Achten Sie auf kurze Sprints, ein sichtbares Backlog, Demos, an denen Sie teilnehmen können, und schriftliche Statusberichte.
3. Wie gehen sie mit der Überlappung um? Fragen Sie nach den genauen Meeting-Zeitfenstern, wer sie abdeckt und was mit dringenden Problemen außerhalb davon geschieht.
4. Wie sieht der Qualitätsprozess aus? Code-Review, automatisierte Tests, eine Staging-Umgebung und eine Definition of Done, die Sie lesen können.
5. Wie gehen sie mit Sicherheit um? Zugriffskontrolle, Secrets, Geräterichtlinie und wie Produktionszugriff gewährt und entzogen wird.
6. Was passiert, wenn jemand ausscheidet? Ersatzprozess, Übergabedokumentation und Kündigungsfristen.
7. Wem gehört was? Prüfen Sie die IP-Übertragung und die Repository-Struktur mit Ihrem Anwalt.
8. Wo liegen die Daten? Standorte, Unterauftragsverarbeiter und ein Auftragsverarbeitungsvertrag, den sie tatsächlich unterschreiben.
9. Können Sie mit ähnlichen Kunden sprechen? Rufen Sie Referenzen aus vergleichbaren Projekten an.
10. Wie sieht der Exit-Plan aus? Sie sollten die Arbeit mit sämtlichem Code, allen Zugangsdaten und der gesamten Dokumentation an ein anderes Team oder intern übergeben können, ohne dass die Kooperation des Anbieters Verhandlungssache ist.

Ein bezahlter Pilot ist die beste Due Diligence überhaupt: Nichts zeigt Kommunikationsgewohnheiten und Codequalität schneller. Wenn Sie auch typische Fallstricke abwägen, behandelt unser Artikel über Fehler von Agenturen beim Outsourcing von Softwareentwicklung mehrere davon aus Kundensicht.

Wann Onshore die richtige Wahl ist

Wir bauen für Kunden remote, und wir sagen dennoch klar: Manchmal sollten Sie lokal einstellen. Onshore ist meist die bessere Wahl, wenn:

• Die Daten oder das System hochsensibel oder reguliert sind und Ihre Compliance-Abteilung verlangt, dass Personal innerhalb einer bestimmten Rechtsordnung arbeitet, mit Kontrollen vor Ort oder bestimmten Sicherheitsfreigaben.
• Das Produkt zu ungewiss ist, um es zu spezifizieren. Wenn jede Woche neue Entscheidungen bringt und Sie Entwickler gemeinsam mit Vertrieb, Betrieb und Kunden im Raum brauchen, sparen eine gemeinsame Zeitzone und ein gemeinsamer Ort mehr, als sie kosten.
• Beschaffungs- oder Vergaberegeln lokale Lieferanten bevorzugen. Manche Käufer am Golf und in Europa verlangen eine lokale Gesellschaft, lokale Präsenz oder Local-Content-Zusagen. In diesen Fällen passt ein Remote-Anbieter womöglich nur als Subunternehmer eines lokalen Hauptauftragnehmers.
• Sie eine Remote-Beziehung noch nicht steuern können. Wenn auf Ihrer Seite niemand Prioritäten und Abnahme verantworten kann, verstärkt Distanz das Problem. Beheben Sie das zuerst oder nutzen Sie einen Anbieter, der einen starken Projektmanager stellt.

Wenn nichts davon zutrifft und die Arbeit sich spezifizieren, prüfen und demonstrieren lässt, kann ein gut geführtes Nearshore- oder Offshore-Team starken Mehrwert liefern. Die ehrliche Antwort ist oft eine Mischung, und ein vertrauenswürdiger Anbieter hilft Ihnen, sie zu finden, auch wenn das bedeutet, weniger von der eigenen Kapazität zu empfehlen.

Nächster Schritt

Erstellen Sie eine Vergleichstabelle: Ergänzen Sie für jeden Anbieter der engeren Wahl Ihren Managementaufwand, die Meeting-Last, die Einarbeitung, das Nacharbeitsrisiko, den rechtlichen Aufwand und das Ersatzrisiko zum Satz, jeweils als Einschätzungen gekennzeichnet. Die Rangfolge ändert sich oft. Für eine zweite Meinung zu Ihrer Shortlist sprechen Sie mit unserem Team über individuelle Softwareentwicklung oder sehen Sie sich unseren Service Webentwicklung an.