Nearshoring vs Inhouse 2026 Echte Kosten und ROI für DACH-Mittelstand

Inhouse: Was kostet ein DACH-Entwickler wirklich?

Die meisten Kostenrechnungen für Inhouse-Entwicklung enden beim Bruttogehalt. Das ist der häufigste Fehler in der Budgetierung. Die Total Cost of Employment liegt typischerweise 50 bis 80 Prozent über dem Bruttogehalt, und genau diese Zahl bestimmt, ob sich eine interne Stelle wirtschaftlich trägt.

Ein Mid-Senior-Entwickler im DACH-Raum kostet brutto 65.000 bis 95.000 EUR pro Jahr. Dazu kommen Lohnnebenkosten von 25 bis 35 Prozent: Arbeitgeberanteile zur Sozialversicherung, Berufsgenossenschaft, Umlagen, Schweizer Pensionskassen-Beiträge. Allein dieser Block schlägt mit 18.000 bis 30.000 EUR zusätzlich zu Buche.

Hinzu kommt Recruiting. Eine offene Senior-Entwicklerstelle bleibt im DACH-Raum 2026 durchschnittlich 5 bis 8 Monate unbesetzt. Headhunter-Provisionen liegen bei 18 bis 30 Prozent des Jahresgehalts, also realistisch 12.000 bis 25.000 EUR pro Hire. Wer ohne externe Personalberatung sucht, investiert dafür intern Zeit von Engineering Manager, HR und Geschäftsführung.

Nach Vertragsunterschrift beginnt das Onboarding. Realistisch 3 bis 6 Monate, in denen die neue Person Codebase, Architektur, Tooling und Domain-Wissen aufbaut. In dieser Phase liefert sie 30 bis 60 Prozent der späteren Produktivität. Bei einem Tagessatz-Äquivalent von 800 EUR sind das 30.000 bis 50.000 EUR Produktivitätsverlust pro Hire.

Dazu kommen Office-Kosten (4.000 bis 8.000 EUR pro Jahr und Arbeitsplatz), Equipment (3.000 bis 5.000 EUR initial, 1.000 pro Jahr Refresh), Lizenzen (Jetbrains, GitHub, Cloud-Tools, 2.000 bis 4.000 EUR pro Jahr) und Weiterbildung (1.500 bis 4.000 EUR pro Jahr).

Summiert ergibt das eine Total Cost of Employment von 80.000 bis 160.000 EUR pro Jahr für einen Mid-Senior-Entwickler. Für Senior-Architekten und Tech Leads kann der Wert auf 180.000 bis 220.000 EUR steigen. Diese Zahl muss in jede Make-or-Buy-Entscheidung einfliessen, nicht nur das Gehalt.

Nearshoring: Realistische Kostenstrukturen

Beim Nearshoring ist die Kostenrechnung wesentlich transparenter, weil viele indirekte Posten entfallen. Es gibt grundsätzlich drei Modelle: Stundensatz, dedicated Team und Projekt-Festpreis. Jedes hat seine wirtschaftliche Logik.

Stundensätze bei einem DACH-nahen EU-Partner liegen 2026 typischerweise bei 30 bis 45 EUR für Mid-Entwickler und 45 bis 65 EUR für Senior-Entwickler. Für Spezialisten in Machine Learning, DevOps oder Architektur können Tagessätze von 800 bis 1.100 EUR anfallen. Diese Sätze beinhalten bereits alle Lohnnebenkosten, Office, Equipment, Lizenzen und Weiterbildung des Partners.

Im dedicated Team-Modell mit monatlichem Retainer rechnen Sie mit 8.000 bis 12.000 EUR pro Monat und Entwickler bei Vollzeit-Engagement. Ein dreiköpfiges dediziertes Team kostet also rund 24.000 bis 36.000 EUR pro Monat, also 288.000 bis 432.000 EUR pro Jahr. Dafür erhalten Sie 30 bis 36 Monatsmensch-Tage Kapazität pro Monat, ohne jede zusätzliche Position.

Ad-hoc Projekte oder Sprint-basierte Aufträge bewegen sich typischerweise zwischen 5.000 und 30.000 EUR je nach Umfang. Ein KI-Chatbot-Proof-of-Concept startet bei 6.000 bis 9.000 EUR, eine ERP-Integration liegt bei 15.000 bis 25.000 EUR, eine vollständige Custom-Web-App im Bereich 20.000 bis 40.000 EUR.

Wichtig: Bei Nearshoring entfallen Recruiting, Onboarding-Lag, Office, Equipment und langfristige Verpflichtungen. Sie zahlen für geleistete Arbeit, nicht für Anwesenheit. Kündigungsfristen liegen typischerweise bei 14 bis 30 Tagen. Das macht Nearshoring besonders attraktiv für Mittelständler mit schwankendem Bedarf.

Eine realistische Vergleichsrechnung: Ein dedicated Senior-Entwickler bei 9.500 EUR pro Monat kostet im Jahr 114.000 EUR. Ein vergleichbarer Inhouse-Senior mit allen Nebenkosten kostet 130.000 bis 160.000 EUR. Die Ersparnis liegt nominal bei 15 bis 30 Prozent, bezieht man Onboarding-Verlust und Recruiting ein, eher bei 40 bis 55 Prozent.

Versteckte Kosten und Risiken

Keine der beiden Optionen ist risikofrei. Eine ehrliche Make-or-Buy-Entscheidung muss beide Risikoseiten beleuchten.

Inhouse-Risiken

• Turnover-Risiko: Senior-Entwickler im DACH-Raum wechseln durchschnittlich alle 2,5 bis 3,5 Jahre. Jeder Abgang kostet 50 bis 100 Prozent des Jahresgehalts in Recruiting, Wissensverlust und Einarbeitung des Nachfolgers.
• Scaling-Lag: Wenn die Roadmap mehr Kapazität braucht, dauert eine Neueinstellung 6 bis 9 Monate. In dieser Zeit liegen Projekte oder werden gestaucht.
• Knowledge Silos: Bei kleinen Teams konzentriert sich kritisches Wissen oft auf 1 bis 2 Personen. Fällt eine davon aus, steht ein ganzer Produktbereich still.
• Fixkosten in Krisenzeiten: Inhouse-Personal ist eine Fixkosten-Position. In Auftragseinbrüchen trägt die Personalstruktur weiter, auch wenn Projekte pausieren.

Nearshoring-Risiken

• Kommunikations-Overhead: Wenn Schnittstellen zum internen Team nicht sauber definiert sind, entsteht Reibungsverlust. Mitigation: feste Sprint-Routinen, dedizierter Product Owner intern, wöchentliche Syncs.
• Vendor-Lock-in: Wenn Code, Dokumentation und Architektur-Entscheidungen nur beim Partner liegen, entsteht eine Abhängigkeit. Mitigation: alle Repositories und ADR-Dokumente in Ihren Systemen, regelmässige Architektur-Reviews mit internem Lead.
• Schwankende Qualität: Nicht jeder Partner liefert auf gleichem Niveau. Mitigation: bezahlter Test-Sprint vor langfristigem Engagement, klare Akzeptanzkriterien, Code-Review-Standards.
• Compliance-Unsicherheit: Bei Partnern ausserhalb der EU drohen Drittland-Probleme unter DSGVO. Bei einem DACH-nahen EU-Partner entfällt dieses Risiko vollständig.

Beide Risikoseiten sind beherrschbar. Inhouse braucht Retention-Strategie, Wissensdokumentation und Bench-Kapazität. Nearshoring braucht klare Verträge, Kommunikationsstandards und Quality Gates. Mehr Details zu unserer Vorgehensweise finden Sie auf der Nearshoring-Seite.

ROI-Berechnung mit konkretem Beispiel

Theorie ist gut, ein realistisches Beispiel ist besser. Wir rechnen einen typischen Fall durch: einen Mittelständler mit 60 Mitarbeitenden, der eine Web-Applikation für interne Prozessautomatisierung benötigt. Geschätzter Umfang: 6 Monate Vollzeit-Arbeit von 2 Entwicklern.

Inhouse-Szenario

Annahme: 2 neue Mid-Senior-Entwickler werden eingestellt, da das interne Team ausgelastet ist.

• Total Cost of Employment pro Person: 140.000 EUR pro Jahr
• Projektdauer: realistisch 4 produktive Monate (2 Monate Onboarding-Lag mit reduzierter Output)
• Kosten für 6 Monate Beschäftigung: 2 × 70.000 EUR = 140.000 EUR
• Recruiting (2 Hires × 9.000 EUR): 18.000 EUR
• Onboarding-Lag (geschätzter Produktivitätsverlust 50 Prozent in den ersten 2 Monaten): 23.000 EUR Wert
• Gesamtkosten für effektiv 4 Monate produktive Arbeit: rund 181.000 EUR
• Achtung: nach Projektende laufen die Stellen weiter, das ist eine langfristige Fixkostenbindung

Nearshoring-Szenario

Annahme: 2 dedicated Nearshoring-Entwickler werden für 6 Monate eingebunden.

• Monatlicher Retainer pro Person: 9.500 EUR
• Gesamtkosten für 6 Monate: 2 × 9.500 EUR × 6 = 114.000 EUR
• Recruiting: 0 EUR
• Onboarding-Lag: minimal (typischerweise 1 bis 2 Wochen Einarbeitung in Codebase)
• Gesamtkosten für 6 Monate produktive Arbeit: 114.000 EUR
• Nach Projektende: keine Verpflichtungen, Kündigungsfrist 30 Tage

Vergleich und Bewertung

Der Nearshoring-Pfad ist nominal 67.000 EUR günstiger und liefert zusätzlich 2 Monate mehr produktive Arbeit. Noch wichtiger: keine langfristige Fixkostenbindung. Wenn nach Projektabschluss kein weiterer Bedarf besteht, endet das Engagement sauber. Beim Inhouse-Szenario laufen die Personalkosten weiter, auch wenn das Folgeprojekt erst in 4 Monaten startet.

Diese Rechnung verschiebt sich zugunsten Inhouse, wenn es um langfristige Kern-Plattformen mit hoher IP-Sensibilität geht. Für projektorientierten Bedarf, Skalierung und spezialisierte Anforderungen bleibt Nearshoring überlegen.

Wann Inhouse, wann Nearshoring, wann beides

Es gibt keine pauschale Antwort. Die Entscheidung folgt einem Framework aus vier Kriterien.

1. Projektnatur: Wiederkehrende Kernaufgaben mit starker Wissenskontinuität passen gut zu Inhouse. Zeitlich begrenzte Projekte, Spitzenlast oder Spezialthemen passen besser zu Nearshoring.

2. IP-Sensibilität: Strategische Algorithmen, Wettbewerbsvorteile und propritäres Wissen sollten intern entwickelt werden. Standardisierbare Module, Integrationen und UI-Layer lassen sich extern gut abdecken.

3. Skalierungsbedarf: Wenn Sie binnen 4 bis 8 Wochen mehr Kapazität brauchen, ist Inhouse keine Option. Nearshoring kann diese Geschwindigkeit liefern.

4. Teamgrösse heute: Unter 3 internen Entwicklern entsteht hohes Bus-Faktor-Risiko. Ein hybrides Modell mit 2 bis 3 internen Senioren plus Nearshoring-Skalierung ist oft die robusteste Konstellation.

Das Hybrid-Modell ist für DACH-Mittelständler mit 30 bis 100 Mitarbeitenden häufig die wirtschaftlichste Variante: ein interner Architekt oder Tech Lead, der die Produkt- und Architekturhoheit behält, plus ein Nearshoring-Team für Umsetzung und Skalierung. Das Know-how bleibt im Haus, die Kosten bleiben variabel.

Praxis-Tipps für die Auswahl

Wer eine Nearshoring-Partnerschaft eingeht, sollte fünf Auswahlkriterien systematisch prüfen.

1. Referenzen mit messbaren Ergebnissen: Nicht nur Logos, sondern konkrete Projektergebnisse mit Zahlen. Fragen Sie nach einer Referenz, die Sie direkt sprechen dürfen.
2. Tech-Stack-Fit: Der Partner sollte Ihren Tech-Stack nicht nur kennen, sondern produktiv darin arbeiten. Prüfen Sie GitHub-Profile der konkret zugewiesenen Entwickler.
3. Kommunikationsstandards: Sprint-Länge, Standup-Rhythmus, Demo-Frequenz, Reporting-Format. Wer diese Punkte nicht im ersten Gespräch beantworten kann, hat keine Prozesse.
4. Vertragliche Absicherung: NDA, Auftragsverarbeitungsvertrag nach Art. 28 DSGVO, IP-Transfer-Klauseln, Source-Code-Eigentum. Diese Dokumente müssen vor Projektstart unterschrieben sein.
5. Test-Sprint: Vereinbaren Sie einen bezahlten Test-Sprint von 2 bis 4 Wochen mit klaren Erfolgskriterien, bevor Sie eine langfristige Bindung eingehen.

Zusätzlich empfiehlt sich ein klarer Kommunikationsstandard: zweiwöchige Sprints, tägliche kurze Standups, wöchentliches Demo, monatliches Stakeholder-Review. Diese Frequenz hat sich in der Praxis als optimal erwiesen, um Kontrolle zu behalten ohne Mikromanagement.

Wer diese Punkte sauber umsetzt, hat die wichtigsten Nearshoring-Risiken bereits adressiert und kann die wirtschaftlichen Vorteile voll realisieren. Mehr zu unserem Vorgehen finden Sie in unseren Software-Entwicklungsleistungen oder beim Thema KI-Automatisierung und Website-Entwicklung.

Fazit: Total Cost statt Stundensatz vergleichen

Die ehrliche Antwort auf «Inhouse oder Nearshoring» lautet: rechnen Sie die Total Cost of Employment vollständig durch und vergleichen Sie sie mit dem Nearshoring-Retainer über den gleichen Zeitraum. Beziehen Sie Onboarding-Lag, Recruiting und Turnover-Risiko mit ein. In den meisten Fällen ergibt sich daraus ein hybrides Modell: interne Kern-Mannschaft für Strategie und IP, Nearshoring für Skalierung und Umsetzung.

Für DACH-Mittelständler mit 30 bis 100 Mitarbeitenden ist das 2026 die wirtschaftlich tragfähigste Konstellation. Sie kombiniert die Stabilität und Wissenskontinuität interner Teams mit der Flexibilität und Kosteneffizienz eines DACH-nahen EU-Partners.