Wer in Deutschland eine Softwarefirma in der Türkei sucht, stellt meist die falsche Frage zuerst. "Welche ist die beste?" lässt sich nicht sinnvoll beantworten, weil der Markt aus mindestens vier grundverschiedenen Anbietertypen besteht, die unterschiedliche Probleme lösen. Ein Anbieter, der für ein Startup mit unklarem Scope hervorragend funktioniert, ist für einen Mittelständler mit Compliance-Anforderungen die falsche Wahl — und umgekehrt.
Dieser Leitfaden ordnet den Markt, nennt realistische Preisbänder, erklärt den Punkt, an dem die meisten Auswahlprozesse datenschutzrechtlich scheitern, und listet die Warnsignale, die einen Anbieter disqualifizieren sollten.
Warum die Frage 2026 anders steht
In Deutschland sind laut Bitkom rund 109.000 IT-Stellen unbesetzt. Eine offene Position bleibt es im Schnitt fast acht Monate. 85 Prozent der Unternehmen berichten von Engpässen bei der Besetzung, und etwa jedes vierte erhält auf eine ausgeschriebene IT-Stelle praktisch keine Bewerbungen. Das Problem ist damit längst nicht mehr die Auswahl unter Kandidaten, sondern dass keine kommen.
Gleichzeitig hat sich das Preisgefüge im europäischen Nearshoring verschoben. Die Gehälter in Polen und Rumänien sind in den letzten Jahren deutlich in Richtung westeuropäisches Niveau gestiegen, wodurch der Kostenabstand zu diesen Märkten geschrumpft ist. Die Türkei liegt weiterhin darunter, bei einem Zeitversatz von ein bis zwei Stunden zu Mitteleuropa — nah genug, dass sich die Arbeitstage fast vollständig überlappen.
Das erklärt, warum die Frage überhaupt gestellt wird. Es erklärt nicht, wie man auswählt.
Vier Anbietertypen im Vergleich
| Typ | Passt für | Typische Größe | Risiko |
|---|---|---|---|
| Boutique-Agentur | Produktentwicklung mit unklarem Scope, enge Zusammenarbeit | 10–50 Personen | Kapazitätsgrenze bei Wachstum |
| Body-Shop / Staffing | Bekannter Bedarf, definierte Rollen, eigenes Engineering-Management vorhanden | 50–500 Personen | Wechselnde Besetzung, wenig Produktverantwortung |
| Talent-Marktplatz | Einzelne Profile, kurzfristige Lücken | Plattform, kein Team | Kein gemeinsames Kontextwissen, Qualität stark streuend |
| Großanbieter | Langlaufende Enterprise-Programme mit formalem Vergabeprozess | 500+ Personen | Prozessoverhead, Senior-Profile oft nur im Angebot |
Die häufigste Fehlbesetzung in der Praxis: ein Unternehmen ohne internes Engineering-Management beauftragt einen Body-Shop. Der Anbieter stellt Kapazität, aber niemand trifft Produktentscheidungen — das Ergebnis ist ausgelastete Zeit ohne Fortschritt. Wer intern niemanden hat, der ein Backlog priorisieren kann, braucht einen Anbieter, der Produktverantwortung mit übernimmt.
Umgekehrt ist eine Boutique-Agentur die falsche Wahl, wenn Sie bereits ein starkes internes Team haben und schlicht zusätzliche Hände für klar definierte Arbeit brauchen. Dann zahlen Sie für Beratungsleistung, die Sie nicht benötigen.
Die sechs Kriterien, die wirklich entscheiden
1. Wer arbeitet tatsächlich am Projekt. Angebote nennen gern ein Team von Senior-Entwicklern; besetzt wird dann mit Junioren unter Aufsicht. Lassen Sie sich die konkreten Profile nennen, die dem Projekt zugeordnet werden, nicht die Firmenübersicht. Ein Anbieter, der das nicht schriftlich zusagen will, sagt damit etwas aus.
2. Sprachverfügbarkeit auf der richtigen Ebene. Englisch ist im türkischen Tech-Sektor Standard. Deutsch ist durch die engen Verbindungen zwischen beiden Ländern verbreitet, aber nicht flächendeckend im Engineering. Entscheidend ist, dass Deutsch dort verfügbar ist, wo Anforderungen geklärt werden — auf Projektleitungsebene. Ob der Backend-Entwickler Deutsch spricht, ist praktisch irrelevant.
3. Vertragspartner und Gerichtsstand. Ein Vertrag mit einer türkischen Gesellschaft ohne europäische Präsenz bedeutet im Streitfall Rechtsverfolgung in der Türkei. Anbieter mit einer Gesellschaft oder Niederlassung im EU-Raum reduzieren dieses Risiko erheblich. Fragen Sie, wer den Vertrag zeichnet und welches Recht gilt.
4. Datenschutzkonstruktion. Dazu unten mehr — es ist der Punkt, an dem die meisten Auswahlprozesse scheitern.
5. Wissensübergabe von Anfang an. Dokumentation und Übergabeprotokolle gehören in die laufende Arbeit, nicht ans Projektende. Anbieter, die Wissen bewusst bei sich konzentrieren, machen den Ausstieg teurer als den Einstieg. Fragen Sie konkret, was Sie nach drei Monaten in der Hand hätten, wenn Sie kündigen.
6. Bereitschaft, Nein zu sagen. Das verlässlichste Signal im gesamten Auswahlprozess. Ein Anbieter, der auf jede Anforderung mit "machen wir" antwortet, hat entweder nicht zugehört oder plant Nachforderungen. Wer im ersten Gespräch benennt, was er nicht kann und wo Ihr Vorhaben nicht zu ihm passt, arbeitet mit höherer Wahrscheinlichkeit auch später ehrlich.
Preisbänder: was realistisch ist
Marktübliche Sätze für Nearshore-Entwicklung liegen bei etwa 40 bis 60 Euro pro Stunde. Vergleichbare Senior-Profile kosten in Deutschland eher 120 bis 150 Euro. Das ist ein Faktor von zwei bis drei.
Auf Projektebene bedeutet das grob:
| Vorhaben | Marktübliches Band |
|---|---|
| MVP mit klar begrenztem Funktionsumfang | 20.000 – 35.000 € |
| Anwendung mit ausgebautem Funktionsumfang | 40.000 – 80.000 € |
| Plattform mit mehreren Rollen und Integrationen | ab 90.000 € |
| Laufende Wartung und Weiterentwicklung | 10–20 % der Entwicklungskosten pro Jahr |
Der Stundensatz ist dabei die am leichtesten zu vergleichende und zugleich am wenigsten aussagekräftige Zahl. Entscheidend sind die Gesamtkosten bis zum ausgelieferten Ergebnis: Einarbeitungszeit, Abstimmungsaufwand, Nacharbeit durch Missverständnisse und der Anteil an Arbeit, der später ohnehin neu geschrieben wird. Ein Team zu 45 Euro, das doppelt so lange braucht, ist teurer als eines zu 60 Euro, das beim ersten Mal trifft.
Wenn ein Angebot deutlich unter dem Marktband liegt, ist die richtige Frage nicht "warum so günstig", sondern "welche Senioritätsstufe wird tatsächlich besetzt". Ausführlicher dazu in unserer Kostenübersicht zum Nearshoring.
Vertragsmodelle: was wann passt
Die Modellwahl entscheidet mehr über den Projektverlauf als der Stundensatz, und die meisten Enttäuschungen entstehen aus einem falsch gewählten Modell, nicht aus schlechter Arbeit.
| Modell | Passt für | Risiko |
|---|---|---|
| Festpreis | Wirklich abgrenzbarer Umfang: eine Migration, eine spezifizierte Schnittstelle | Risikopuffer im Preis, Nachverhandlung über Change Requests |
| Time & Material | Laufende Produktentwicklung mit sich änderndem Backlog | Ohne Budgetdeckel schwer steuerbar |
| Dediziertes Team | Feste Kapazität ab etwa drei Monaten, Wissen soll im Team wachsen | Braucht Produktentscheidungen auf Ihrer Seite |
Der häufigste Fehler ist der Festpreis für etwas, das noch nicht spezifiziert ist. Beide Seiten wissen im Grunde, dass der Umfang sich ändern wird — der Anbieter preist einen Puffer ein, Sie zahlen ihn auch dann, wenn der Fall nicht eintritt, und für alles Zusätzliche kommt ohnehin ein Change Request. Ehrlicher ist ein Time-and-Material-Modell mit vereinbartem Budgetdeckel: Sie zahlen tatsächlichen Aufwand, aber nicht unbegrenzt.
Für laufende Arbeit ist das dedizierte Team die tragfähigste Konstruktion, weil Kontextwissen im Team bleibt statt bei jedem Wechsel neu aufgebaut zu werden. Die Voraussetzung ist allerdings, dass jemand bei Ihnen das Backlog priorisieren kann. Fehlt diese Rolle, entsteht Auslastung ohne Fortschritt — und das ist teurer als jeder Stundensatz. Details zum Ablauf auf unserer Seite zum dedizierten Entwicklungsteam.
Die ersten 90 Tage
Ob eine Zusammenarbeit trägt, zeigt sich früh. Ein Aufbau, der das Risiko klein hält, sieht ungefähr so aus:
Wochen 1–2: Verträge und Zugriffe. Rahmenvertrag, Auftragsverarbeitungsvertrag, Standardvertragsklauseln, und die Entscheidung, welche Daten das Team überhaupt sieht. Parallel Repository-, CI- und Ticketsystem-Zugänge. Dieser Block ist fast immer der eigentliche Engpass, nicht die Verfügbarkeit von Entwicklern — planen Sie ihn ein, statt sich davon überraschen zu lassen.
Wochen 3–6: eine bewusst kleine erste Lieferung. Nicht das wichtigste Feature, sondern eines, das den gesamten Weg abbildet: Ticket, Entwicklung, Review, Test, Deployment. Sie lernen daraus mehr über die Zusammenarbeit als aus jeder Referenzliste — wie präzise Rückfragen gestellt werden, wie Code Reviews beantwortet werden, ob Schätzungen halten. Kapazität wird erst hochgefahren, wenn dieser Durchlauf sauber funktioniert.
Wochen 7–12: Skalierung und Übergabekultur. Jetzt lohnt es sich, das Team zu vergrößern. Gleichzeitig sollte Dokumentation zur Routine werden, nicht zum Projektende verschoben: Architekturentscheidungen schriftlich, Onboarding-Notizen aktuell, Übergabeprotokolle gepflegt. Der Test dafür ist einfach — könnte ein neuer Entwickler in zwei Tagen produktiv werden? Wenn nein, wächst gerade eine Abhängigkeit, die Sie später teuer bezahlen.
Wer diesen Ablauf umdreht und mit voller Kapazität startet, bevor der erste Durchlauf funktioniert hat, vervielfacht die Kosten eines Fehlgriffs.
DSGVO: der Punkt, an dem Auswahlprozesse scheitern
Hier wird es unbequem, und dieser Abschnitt ist der Grund, warum viele gut begonnene Auswahlprozesse in der Rechtsabteilung enden.
Die EU-Kommission hat am 13. Dezember 2023 festgestellt, dass das türkische Datenschutzrecht nicht als gleichwertig mit der DSGVO gilt. Es gibt also keinen Angemessenheitsbeschluss für die Türkei. Personenbezogene Daten dürfen übermittelt werden, aber nur über einen Transfermechanismus nach Kapitel V der DSGVO.
Praktisch heißt das: Ein Auftragsverarbeitungsvertrag nach Art. 28 allein reicht nicht. Erforderlich sind zusätzlich Standardvertragsklauseln nach Art. 46, eine dokumentierte Risikoabwägung für den Drittlandtransfer und technische Maßnahmen, die die identifizierten Risiken auch tatsächlich adressieren.
Die türkische Reform des KVKK von 2024 hat dafür ein an der DSGVO orientiertes Regelwerk für Standardvertragsklauseln eingeführt. Das erzeugt keinen Angemessenheitsbeschluss, macht die vertragliche Konstruktion aber auf türkischer Seite belastbarer.
Der wirksamste Hebel ist am Ende nicht juristisch, sondern architektonisch: Wenn Produktivdaten die EU nie verlassen, das Entwicklungsteam gegen anonymisierte oder synthetische Datensätze arbeitet und Zugriffe auf Produktivsysteme eng begrenzt und protokolliert sind, schrumpft der Drittlandtransfer auf einen kleinen, kontrollierbaren Rest.
Fragen Sie jeden Anbieter, wie er das löst. Wer die Frage mit "wir sind DSGVO-konform" beantwortet, ohne Art. 46 zu erwähnen, hat sie nicht verstanden. Details in unserem Leitfaden zur DSGVO beim Nearshoring.
Was Sie vor dem ersten Gespräch vorbereiten sollten
Die Qualität der Angebote, die Sie bekommen, hängt unmittelbar davon ab, wie präzise Sie die Ausgangslage beschreiben können. Drei Dinge lohnen sich vorher:
Der Ist-Zustand, ehrlich. Welche Systeme laufen bereits, wo hakt es, was ist über die Jahre gewachsen und würde heute niemand mehr so bauen. Anbieter, die diesen Teil nicht erfahren, kalkulieren die Integration in bestehende Systeme systematisch zu niedrig — und genau dort entstehen später die Nachforderungen.
Die Entscheidung, wer intern verantwortlich ist. Nicht wer das Projekt genehmigt, sondern wer wöchentlich Prioritäten setzt und Rückfragen innerhalb eines Tages beantwortet. Fehlt diese Person, ist das ein Grund zu warten, kein Grund für ein anderes Modell.
Was in sechs Monaten anders sein soll. Nicht als Funktionsliste, sondern als Ergebnis: welcher Prozess läuft dann schneller, welche Zahl sieht anders aus. Anbieter, die daraufhin den Umfang reduzieren statt ihn zu vergrößern, sind meist die richtigen.
Fünf Warnsignale
- Festpreis vor dem ersten inhaltlichen Gespräch. Entweder ist ein großzügiger Risikopuffer eingepreist, oder es kommen Change Requests.
- Referenzen ohne nachprüfbare Details. Logos auf einer Seite sind keine Referenz. Nachprüfbar heißt: Ansprechpartner, Zeitraum, konkreter Leistungsumfang.
- "DSGVO-konform" als Behauptung. Ohne Nennung des Transfermechanismus ist das eine Marketingaussage, keine Rechtsposition.
- Keine Aussage zur Besetzung. Wenn nicht schriftlich zugesagt wird, wer im Team arbeitet, wird die Besetzung nach Vertragsschluss zur Verhandlungsmasse.
- Zustimmung zu allem. Ein Anbieter ohne Grenzen hat keine Spezialisierung.
Wann die Türkei nicht die richtige Wahl ist
Der Vollständigkeit halber, weil diese Fälle real sind:
Wenn Ihre Rechtsabteilung eine Verarbeitung ausschließlich innerhalb der EU verlangt, sind Polen oder Rumänien die sauberere Antwort. Dort gilt die DSGVO unmittelbar, ein Art.-46-Mechanismus entfällt vollständig. Das ist ein echter struktureller Vorteil dieser Standorte, kein Detail.
Bei Projekten mit Sicherheitsüberprüfung, kritischer Infrastruktur oder öffentlichen Vergabeverfahren mit Standortauflagen scheidet Nearshoring in Drittländer in der Regel ohnehin aus.
Und wenn dauerhafte Präsenz vor Ort Teil der Leistung ist — tägliche Anwesenheit im Werk, in der Klinik, beim Kunden — lässt sich das nicht nearshoren, unabhängig vom Anbieter.
Ein ausführlicher Vergleich zwischen Türkei, Polen, Rumänien und Indien ordnet die Standorte entlang von Kosten, Zeitzone und Datenschutzstatus ein.
Zwölf Fragen für das erste Gespräch
- Welche konkreten Profile werden dem Projekt zugeordnet, und wird das schriftlich zugesagt?
- Wer ist Vertragspartner, und welches Recht gilt?
- Über welchen Mechanismus nach Art. 46 DSGVO läuft der Datentransfer?
- Bleiben Produktivdaten in der EU? Wenn nein, warum nicht?
- Gegen welche Daten entwickelt das Team — Produktivdaten, anonymisiert oder synthetisch?
- Wie werden Zugriffsrechte vergeben und protokolliert?
- Auf welcher Ebene ist Deutsch verfügbar?
- Wie sieht der Abrechnungsmodus aus, und was ist explizit nicht enthalten?
- Was hätten wir nach drei Monaten in der Hand, wenn wir kündigen?
- Welche Kündigungsfrist gilt, und wie läuft die Wissensübergabe?
- Welche Vorhaben lehnen Sie ab?
- Was ist in den letzten zwölf Monaten in einem Projekt schiefgelaufen, und was wurde daraus geändert?
Die letzte Frage ist die aufschlussreichste. Jeder Anbieter mit echter Projekthistorie hat eine Antwort darauf. Wer keine hat, hat entweder wenig geliefert oder erzählt nicht die ganze Geschichte.
Kurz zusammengefasst
Die Auswahl entscheidet sich nicht an der Referenzliste, sondern an vier Punkten: Passt der Anbietertyp zu Ihrem Vorhaben, ist die Besetzung schriftlich zugesagt, hält die Datenschutzkonstruktion einer Prüfung stand, und ist der Anbieter bereit, Grenzen zu benennen.
Wenn Sie an dem Punkt sind, an dem diese Fragen konkret werden: Wir arbeiten von Istanbul und Berlin aus, und in einem ersten Gespräch klären wir gern zuerst, ob Nearshoring für Ihr Vorhaben überhaupt der richtige Weg ist. Einen Überblick über unser Vorgehen finden Sie auf der Seite zur Nearshore-Softwareentwicklung.
Zwei weiterführende Texte, falls die Entscheidung noch offen ist: Woran sich Angebote vergleichen lassen, steht in Was kostet App-Entwicklung 2026?; wie ein Lastenheft aussehen muss, damit Angebote überhaupt vergleichbar werden, in Lastenheft vs. Pflichtenheft.