Nearshoring nach Ägypten: was deutsche Mittelständler vorher wissen sollten

Nearshoring wird meist als Kostenthema verkauft. Das ist der uninteressanteste Teil. Entscheidend ist, ob Sie am Donnerstagnachmittag jemanden erreichen, der Ihr Problem versteht — und ob die Arbeit, die Sie bezahlen, Ihnen danach auch gehört.

Warum Ägypten und nicht Osteuropa

Osteuropa ist der Standardreflex, und für viele Projekte weiterhin richtig. Die Argumente für Ägypten sind konkreter, als die Kostenrechnung vermuten lässt:

• Zeitzone. Kairo liegt bei ein bis zwei Stunden Versatz zu Deutschland, je

nach Jahreszeit. Ein vollständiger Arbeitstag überlappt — kein Warten auf Antworten bis zum nächsten Morgen, wie bei Südasien.

• Kapazität. Ägypten bildet jährlich eine große Zahl von Ingenieuren aus, und

der Markt ist längst nicht so leergefegt wie Polen oder Tschechien.

• Sprache. Englisch ist in der Branche Arbeitssprache. Deutsch ist es nicht —

dazu unten mehr, denn hier liegt das eigentliche Risiko.

• Preisniveau. Deutlich unter Osteuropa, das seinerseits deutlich unter

Deutschland liegt.

Was es tatsächlich kostet

Richtwerte, keine Angebote. Wer Ihnen ohne Anforderungsdokument eine Festsumme nennt, rät.

Der Unterschied ist real. Er ist aber auch der Grund, warum diese Projekte scheitern: Wer nur auf den Tagessatz schaut, kauft Stunden statt Ergebnisse.

Die drei Risiken, die zählen

1. Wem gehört der Code?

Das deutsche Urheberrecht funktioniert anders als das US-amerikanische Konzept des "work for hire": Das Urheberrecht selbst ist nicht übertragbar, übertragen werden Nutzungsrechte. Bei einem Vertrag mit ausländischem Recht gelten diese Annahmen nicht automatisch.

Regeln Sie im Vertrag ausdrücklich: ausschließliche, unbefristete, übertragbare Nutzungsrechte an allem, was im Projekt entsteht, einschließlich Quellcode. Ohne diesen Satz besitzen Sie möglicherweise eine Lizenz und kein Produkt.

2. DSGVO und Drittlandtransfer

Ägypten hat keinen Angemessenheitsbeschluss der EU-Kommission. Verarbeitet der Dienstleister personenbezogene Daten, brauchen Sie Standardvertragsklauseln, ein Transfer Impact Assessment und einen Auftragsverarbeitungsvertrag.

Der praktisch einfachste Weg: Halten Sie Produktivdaten in der EU. Entwicklung und Wartung finden auf anonymisierten oder synthetischen Daten statt. Das löst den größten Teil des Problems, bevor es entsteht — und ist ohnehin die bessere Ingenieurspraxis.

3. Sprache und Fachlichkeit

Das größte Risiko ist keines der beiden oben. Es ist, dass Ihre Fachlichkeit auf Deutsch existiert und die Umsetzung auf Englisch stattfindet.

Ein Entwickler, der "Rechnungsabgrenzungsposten" nicht kennt, baut ihn falsch — unabhängig von seinem technischen Niveau. Prüfen Sie im Auswahlgespräch nicht Frameworks, sondern ob jemand Ihr Geschäft nach zwanzig Minuten korrekt zusammenfasst.

Nearshoring scheitert selten an der Technik. Es scheitert daran, dass niemand die Anforderung präzise genug beschrieben hat, um sie über eine Sprachgrenze zu tragen.

Wie Sie es richtig aufsetzen

1. Starten Sie mit einem bezahlten Kleinprojekt. Zwei bis vier Wochen, klar

abgegrenzt, mit echtem Ergebnis. Das kostet weniger als ein Fehlgriff und sagt mehr als jede Referenzliste.

1. Bestehen Sie auf Ihrem eigenen Repository. Ihr GitHub, Ihr Cloud-Konto,

Ihre Zugänge. Der Dienstleister arbeitet darin — nicht umgekehrt.

1. Wöchentlich lauffähig, nicht nur Statusbericht. Etwas, das Sie selbst

öffnen und benutzen können.

1. Eine feste Ansprechperson. Kein rotierendes Team, kein Account Manager,

der nicht in den Code sieht.

1. Dokumentation als Abnahmekriterium. Nicht als Nachtrag.

Wann Nearshoring die falsche Antwort ist

Wenn die Anforderungen noch nicht feststehen und sich wöchentlich ändern, ist räumliche und sprachliche Distanz ein Verstärker, kein Sparhebel. Klären Sie das intern, bevor Sie es auslagern.

Ebenso, wenn es um ein System geht, das niemand außer Ihnen versteht und das niemand dokumentiert hat. Übergeben Sie kein Wissen, das nur in einem Kopf existiert.

Häufige Fragen

Brauchen wir jemanden, der Deutsch spricht?

Für die Entwicklung nicht zwingend. Für die Anforderungsaufnahme dringend — oder Sie brauchen jemanden auf Ihrer Seite, der die Fachlichkeit sauber auf Englisch formulieren kann.

Wie steht es um Feiertage und Arbeitswoche?

Die Arbeitswoche ist üblicherweise Sonntag bis Donnerstag, häufig angepasst an Montag bis Freitag bei europäischen Kunden. Klären Sie das vorab, ebenso die Feiertage — sie liegen anders als in Deutschland.

Was passiert, wenn wir die Zusammenarbeit beenden?

Wenn Punkt zwei oben eingehalten wurde: nichts Dramatisches. Code, Zugänge und Dokumentation liegen bereits bei Ihnen. Genau dafür ist er da.