Een nearshore partner kies je op vijf punten: team en continuïteit, werkwijze en communicatie, kwaliteit en beveiliging, contract en eigendom van de code, en de exit. Hieronder staan 15 vragen voor het eerste gesprek. Per vraag lees je waarom je hem stelt en welk antwoord je wilt horen. Een tabel zet daarna alle goede antwoorden en rode vlaggen naast elkaar.
Deze checklist gaat over wat specifiek is aan een team in een ander land: werkuren, taal, reizen, inwerken op afstand, verloop, de juridische entiteit ter plaatse en de overdracht van intellectueel eigendom. De algemene vragen die je elke leverancier stelt, zoals over referenties en de opbouw van een offerte, staan in negen vragen om een softwarebedrijf te kiezen. Ben je nog aan het oriënteren, lees dan eerst wat nearshoring is.
Waarom je een nearshore partner op eigen punten toetst
Organisaties zoeken ontwikkelcapaciteit over de grens, omdat goede ontwikkelaars in eigen land lastig te vinden blijven. Volgens het werkgeversonderzoek van UWV was in het najaar van 2025 47% van de vacatures in de sector informatie en communicatie moeilijk vervulbaar. In de hele EU had 57,5% van de bedrijven die in 2023 specialisten in ICT probeerden aan te nemen daar moeite mee, meldt Eurostat. Dezelfde bron laat zien dat 84% van de Nederlandse bedrijven taken op het gebied van ICT door externe leveranciers laat uitvoeren.
Met een partner in een ander land komen er vragen bij die in een gewoon leveranciersgesprek snel blijven liggen. Je wilt weten wie ter plaatse werkgever is, onder welk recht de code ontstaat en hoe je team en kennis terughaalt als de samenwerking stopt. In de Global Outsourcing Survey 2024 van Deloitte zegt 70% van de ruim 500 ondervraagde bestuurders in de afgelopen vijf jaar een deel van eerder uitbesteed werk weer zelf te hebben opgepakt. Tegelijk wil 80% evenveel of meer in uitbesteding investeren. Een goede exit hoort dus vanaf de eerste dag bij de keuze.
Team en continuïteit
1. Heeft de partner een eigen rechtspersoon in het land waar het team werkt?
Waarom je hem stelt. Een bedrijf met een eigen entiteit ter plaatse is daar de werkgever, kent het lokale arbeidsrecht en is aanspreekbaar. Een tussenpersoon die engineers via derden regelt, heeft minder grip op je team.
Goed antwoord. Een geregistreerde entiteit in het land, een eigen kantoor en gegevens die je zelf kunt nakijken in het handelsregister ter plaatse.
2. Zijn de engineers in loondienst, of werkt de partner met onderaannemers?
Waarom je hem stelt. Freelancers en onderaannemers wisselen sneller van opdracht, en afspraken over geheimhouding en eigendom lopen dan via een extra schakel. Het verschil met zelf werkgever worden in het buitenland lees je in employer of record of nearshore partner.
Goed antwoord. Engineers in vaste dienst van de partner, en onderaanneming alleen met jouw schriftelijke toestemming.
3. Werkt het team vast voor jou, of rouleren engineers tussen klanten?
Waarom je hem stelt. Een dedicated team bouwt kennis op van jouw product, je domein en je collega's. Engineers die steeds tussen klanten wisselen, nemen die kennis telkens mee.
Goed antwoord. Vaste namen per rol, een teamlead die je persoonlijk kent en wijzigingen in de bezetting alleen in overleg met jou.
4. Hoe houdt de partner engineers vast, en hoe hoog is het verloop?
Waarom je hem stelt. Verloop weegt zwaarder bij een team op afstand, omdat inwerken via een scherm trager gaat dan naast elkaar aan een bureau.
Goed antwoord. Een concreet verloopcijfer over de afgelopen jaren, een verhaal over doorgroei en opleiding, en vervanging met overlap, zodat een vertrekkende engineer zijn opvolger zelf inwerkt.
Werkwijze en communicatie
5. Hoeveel werkuren overlappen met die van jouw team?
Waarom je hem stelt. Overlap bepaalt of een vraag binnen het uur een antwoord krijgt of pas de volgende ochtend. Ook feestdagen tellen mee, want elk land heeft eigen vrije dagen.
Goed antwoord. Dezelfde werkdag en een gedeelde kalender met de feestdagen van beide landen. Bosnië en Herzegovina gebruikt bijvoorbeeld dezelfde tijdzone als Nederland en schakelt op dezelfde dagen over op zomertijd.
6. In welke taal werkt het team, en wie is je vaste aanspreekpunt?
Waarom je hem stelt. Tickets, documentatie en overleg gaan meestal in het Engels. Loopt alles via één persoon, dan ontstaat er een flessenhals en een risico als die persoon vertrekt.
Goed antwoord. Engineers die zelf aan je overleggen deelnemen, documentatie in de taal die jouw organisatie gebruikt en een aanspreekpunt dat jouw context kent.
7. Hoe ziet het inwerken in de eerste weken eruit?
Waarom je hem stelt. Bij een team op afstand gaat in de overdracht snel kennis verloren. Toegang tot systemen die na een paar dagen nog niet geregeld is, kost je meteen een week.
Goed antwoord. Een concreet plan met toegang vanaf de eerste dag, kennisoverdracht door jouw eigen mensen, een kleine eerste opdracht en een vast evaluatiemoment.
8. Hoe vaak reist het team, en wie regelt de bezoeken?
Waarom je hem stelt. Een paar dagen samen op één locatie bij de start, en daarna op vaste momenten, bouwt vertrouwen op dat je via video moeilijk haalt.
Goed antwoord. Een afgesproken ritme van bezoeken in beide richtingen en een open uitnodiging om het kantoor van het team te bezoeken.
Kwaliteit en beveiliging
9. Mag je het certificaat voor ISO 27001 van de partner zelf inzien?
Waarom je hem stelt. Veel bedrijven noemen ISO 27001. Wat telt, is welke entiteit en welke locaties onder het certificaat vallen. Een certificaat van een moederbedrijf elders dekt het kantoor van jouw team niet altijd.
Goed antwoord. Een kopie van het certificaat met de naam van de entiteit, een scope waarin de locatie van jouw team staat, een geldige einddatum en de naam van de certificerende instelling, zodat je het zelf kunt navragen.
10. Werkt het team in jouw repository, met jouw tooling en jouw definitie van klaar?
Waarom je hem stelt. Werkt het team in een eigen omgeving, dan zie je pas bij de oplevering wat er gebouwd is. In één gedeelde repository zie je elke wijziging, review en test.
Goed antwoord. Werken in jouw repository en pipeline, codereviews die je eigen ontwikkelaars kunnen meelezen en dezelfde definitie van klaar als je interne team.
11. Hoe is de toegang tot jouw systemen geregeld vanaf de andere locatie?
Waarom je hem stelt. Een team in een ander land werkt via accounts, apparaten en netwerken die jij niet zelf beheert. Je wilt weten wie toegang heeft en hoe snel die vervalt als iemand vertrekt.
Goed antwoord. Persoonlijke accounts die jij uitgeeft of kunt inzien, apparaten die de partner beheert en een vaste procedure bij komst en vertrek van engineers.
Contract en eigendom van code
12. Hoe komt het intellectueel eigendom van de engineer via de partner bij jou?
Waarom je hem stelt. Code ontstaat bij een engineer die onder lokaal arbeidsrecht werkt. Het eigendom moet in elke schakel geregeld zijn: van engineer naar partner en van partner naar jou.
Goed antwoord. Een bepaling die de rechten op code en documentatie aan jou overdraagt, plus de bevestiging dat de arbeidscontracten ter plaatse dat mogelijk maken. Laat deze bepaling toetsen door je eigen jurist.
13. Met welke entiteit teken je, en onder welk recht valt het contract?
Waarom je hem stelt. Bij een meningsverschil maakt het veel uit of je contractpartij in Nederland zit of alleen in het buitenland. Leg ook de afspraken over oplevering vooraf vast, zoals beschreven in acceptatiecriteria in je softwarecontract.
Goed antwoord. Een duidelijke contractpartij, het toepasselijke recht en de plek waar geschillen worden beslecht staan zwart op wit in het contract.
Exit en overdracht
14. Wat krijg je mee als de samenwerking stopt?
Waarom je hem stelt. Zonder exitafspraken blijft kennis achter in de hoofden van mensen die je daarna niet meer spreekt.
Goed antwoord. Een vastgelegde overdrachtsperiode, documentatie die tijdens het werk wordt bijgehouden, alle toegang en accounts bij jou en hulp bij het inwerken van je volgende team.
15. Mag je engineers later overnemen of het werk naar je eigen team halen?
Waarom je hem stelt. Sommige organisaties willen op termijn zelf een team opbouwen. Een strikt overnameverbod zonder einddatum maakt dat lastig.
Goed antwoord. Heldere afspraken over het overnemen van mensen, een redelijke overgangsperiode en een partner die meedenkt over het terughalen van kennis.
De 15 vragen op een rij met rode vlaggen
| Vraag | Goed antwoord | Rode vlag |
|---|---|---|
| 1. Eigen rechtspersoon | Entiteit en kantoor in het land | Alleen een agent of tussenpersoon |
| 2. Loondienst | Engineers in vaste dienst | Onbekende onderaannemers |
| 3. Vast team | Vaste namen per rol | Bezetting wisselt zonder overleg |
| 4. Verloop | Cijfer en vervanging met overlap | Geen cijfer beschikbaar |
| 5. Werkuren | Dezelfde werkdag, gedeelde kalender | Overleg alleen buiten kantoortijd |
| 6. Taal | Engineers praten zelf mee | Alles via één tussenpersoon |
| 7. Inwerken | Plan met toegang vanaf dag één | Starten zonder plan |
| 8. Reizen | Vast ritme van bezoeken | Bezoek aan het kantoor ontmoedigd |
| 9. ISO 27001 | Certificaat met scope inzien | Alleen een logo op de website |
| 10. Repository | Werk in jouw omgeving | Code pas bij oplevering zichtbaar |
| 11. Toegang | Persoonlijke accounts, vaste procedure | Gedeelde accounts |
| 12. Eigendom | Overdracht in elke schakel | Rechten blijven bij de partner |
| 13. Contractpartij | Partij en recht helder | Onduidelijk met wie je tekent |
| 14. Exit | Overdrachtsperiode vastgelegd | Niets geregeld voor het einde |
| 15. Overname | Afspraken met einddatum | Verbod zonder einddatum |
Zo gebruik je de checklist in gesprekken
Stuur de vragen vooraf, zodat de partner bewijs kan meenemen, zoals het certificaat en een verloopcijfer. Bel een klant die al een paar jaar met de partner werkt en bezoek het kantoor waar je team komt te zitten.
Isatis werkt zelf volgens dit model, met teams in Nijmegen en Sarajevo. We bouwen al meer dan dertig jaar software, met 30+ engineers en meer dan 100 projecten, en zijn gecertificeerd voor ISO 9001 en ISO 27001. Wil je onze antwoorden op deze 15 vragen horen, lees dan over nearshore teamuitbreiding of plan een gesprek.
Veelgestelde vragen
Wat is een nearshore partner?
Een nearshore partner is een softwarebedrijf in een nabijgelegen land dat een dedicated team of losse engineers levert voor jouw product. De engineers zijn bij de partner in dienst en werken in dezelfde of een aangrenzende tijdzone. Jij bepaalt wat er gebouwd wordt; de partner zorgt voor de mensen.
Waarin verschilt een nearshore partner kiezen van een softwarebedrijf kiezen?
De basis is gelijk: continuïteit, eigendom van de code en heldere afspraken. Bij een nearshore partner komen daar vragen bij over werkuren, taal, reizen, inwerken op afstand, de entiteit in het andere land en de overdracht van intellectueel eigendom onder lokaal recht.
Hoeveel werkuren overlap heb je nodig met een nearshore team?
Zoveel mogelijk. Met een partner in dezelfde tijdzone, zoals een team in Sarajevo, deel je de hele werkdag. Dan kan het team meedoen aan je dagstart, overleg en releases.
Hoe controleer je het certificaat voor ISO 27001 van een nearshore partner?
Vraag een kopie op en kijk naar vier dingen: de naam van de entiteit, de scope met de locatie van het team, de einddatum en de certificerende instelling. Bij die instelling kun je navragen of het certificaat geldig is.
Kun je een nearshore team later zelf overnemen?
Dat hangt af van het contract. Leg vooraf vast of en wanneer je engineers mag overnemen en hoe de overdracht van kennis en toegang verloopt. Een goede partner bespreekt dat open, ook al gaat het over het einde van de samenwerking.
