To choose a nearshore partner, test five areas: team and continuity, ways of working and communication, quality and security, contract and code ownership, and the exit. Below are 15 questions for your first conversation. For each one, you'll read why it matters and what you want to hear. A table then sets out the good answers and red flags side by side.
This checklist covers what is specific to a team in another country: working hours, language, travel, remote onboarding, turnover, the local legal entity, and the transfer of intellectual property. General vendor questions, such as references and quotes, are in nine questions to choose a software company. If you're still exploring the model, start with what nearshoring is.
Why a nearshore partner needs its own questions
Organisations look across borders for development capacity because good developers remain hard to find. In 2023, 57.5% of EU enterprises that recruited or tried to recruit ICT specialists had difficulty filling those vacancies, according to Eurostat. Dutch employment agency UWV found that 47% of vacancies in the information and communication sector were hard to fill in autumn 2025. Outsourcing is already common: Eurostat reports that 84% of Dutch enterprises have ICT functions performed by external suppliers.
With a partner abroad, you also want to know who the employer is on the ground, under which law the code is created, and how you bring your team and knowledge back if the partnership ends. In Deloitte's Global Outsourcing Survey 2024, 70% of more than 500 executives said they had brought some previously outsourced work back in house over the past five years. At the same time, 80% plan to maintain or increase their investment in outsourcing. A good exit belongs in the decision from day one.
Team and continuity
1. Does the partner have its own legal entity in the country where the team works?
Why ask it. A company with its own local entity is the employer there and can be held accountable. An intermediary sourcing engineers through third parties has less control over the people building your software.
What you want to hear. A registered entity in the country, its own office, and details you can check yourself in the local business register.
2. Are the engineers employed by the partner, or does it use subcontractors?
Why ask it. Subcontractors move between assignments faster, and confidentiality and ownership then run through an extra link. Compare this with being the employer yourself in employer of record vs a nearshore partner.
What you want to hear. Engineers on permanent contracts with the partner, and subcontracting only with your written consent.
3. Does the team work only for you, or do engineers rotate between clients?
Why ask it. A dedicated team builds knowledge of your product, your domain, and your colleagues. Engineers who keep switching between clients take that knowledge with them every time.
What you want to hear. Named people per role, a team lead you know personally, and changes to the lineup only after you agree.
4. How does the partner keep its engineers, and how high is staff turnover?
Why ask it. Turnover hurts more with a remote team, because onboarding through a screen is slower than sitting side by side.
What you want to hear. An actual turnover figure for recent years, a clear story about growth and training, and replacements with overlap, so a departing engineer onboards their successor.
Ways of working and communication
5. How many working hours overlap with your team?
Why ask it. Overlap decides whether a question gets answered within the hour or the next morning. Public holidays count too, because every country has its own.
What you want to hear. The same working day and a shared calendar with both countries' public holidays. Bosnia and Herzegovina, for example, uses the same time zone as the Netherlands and switches to summer time on the same dates.
6. Which language does the team work in, and who is your main contact?
Why ask it. Tickets, documentation, and meetings usually run in English. If everything goes through one person, you get a bottleneck and a risk when that person leaves.
What you want to hear. Engineers who join your meetings themselves, documentation in the language your organisation uses, and a contact who understands your context.
7. What do the first weeks of onboarding look like?
Why ask it. With a remote team, knowledge easily gets lost in the handover. System access that still isn't sorted after a few days costs you a week straight away.
What you want to hear. A concrete plan with access from day one, knowledge transfer by your own people, a small first assignment, and a fixed review moment.
8. How often does the team travel, and who arranges the visits?
Why ask it. A few days together at the start, and regularly after that, builds trust that's hard to achieve over video.
What you want to hear. An agreed rhythm of visits in both directions and an open invitation to visit the team's office.
Quality and security
9. Can you see the partner's own ISO 27001 certificate?
Why ask it. Many companies mention ISO 27001. What matters is which entity and which locations the certificate covers. A certificate held by a parent company elsewhere doesn't always cover the office where your team sits.
What you want to hear. A copy of the certificate with the entity's name, a scope that includes your team's location, a valid expiry date, and the name of the certification body, so you can verify it yourself.
10. Does the team work in your repository, with your tools and your definition of done?
Why ask it. If the team works in its own environment, you only see what was built at delivery. In one shared repository you see every change, review, and test.
What you want to hear. Work in your repository and pipeline, code reviews your own developers can follow, and the same definition of done as your internal team.
11. How is access to your systems arranged from the other location?
Why ask it. A team in another country works through accounts, devices, and networks you don't manage yourself. You want to know who has access and how quickly it's removed when someone leaves.
What you want to hear. Personal accounts that you issue or can review, devices managed by the partner, and a fixed procedure when engineers join or leave.
Contract and code ownership
12. How does intellectual property pass from the engineer, through the partner, to you?
Why ask it. Code is written by an engineer working under local employment law. Ownership has to be settled at every link: from engineer to partner, and from partner to you.
What you want to hear. A clause that assigns the rights to code and documentation to you, plus confirmation that the local employment contracts allow it. Have your own lawyer review this clause.
13. Which entity do you sign with, and which law governs the contract?
Why ask it. In a dispute, it matters a great deal whether your contracting party is based in your own country or only abroad. Agree on delivery up front as well, as described in acceptance criteria in your software contract.
What you want to hear. A clear contracting party, the governing law, and the place where disputes are settled, all in writing.
Exit and handover
14. What do you take with you if the partnership ends?
Why ask it. Without exit agreements, knowledge stays in the heads of people you no longer talk to.
What you want to hear. A defined handover period, documentation kept up to date during the work, all access and accounts in your hands, and help onboarding your next team.
15. Can you take over engineers later, or move the work to your own team?
Why ask it. Some organisations want to build their own team over time. A strict ban on hiring the partner's engineers, with no end date, makes that hard.
What you want to hear. Clear agreements on taking over people, a reasonable transition period, and a partner willing to help you bring knowledge back in house.
The 15 questions at a glance, with red flags
| Question | Good answer | Red flag |
|---|---|---|
| 1. Own legal entity | Entity and office in the country | Only an agent or intermediary |
| 2. Employment | Engineers on permanent contracts | Unknown subcontractors |
| 3. Dedicated team | Named people per role | Lineup changes without notice |
| 4. Turnover | Figure and overlapping replacement | No figure available |
| 5. Working hours | Same working day, shared calendar | Meetings only outside office hours |
| 6. Language | Engineers join the conversation | Everything through one intermediary |
| 7. Onboarding | Plan with access from day one | Starting without a plan |
| 8. Travel | Regular rhythm of visits | Office visits discouraged |
| 9. ISO 27001 | Certificate and scope shared | Only a logo on the website |
| 10. Repository | Work in your environment | Code visible only at delivery |
| 11. Access | Personal accounts, fixed procedure | Shared accounts |
| 12. Ownership | Assignment at every link | Rights stay with the partner |
| 13. Contracting party | Party and law are clear | Unclear who you sign with |
| 14. Exit | Handover period agreed | Nothing arranged for the end |
| 15. Takeover | Agreements with an end date | Ban with no end date |
How to use the checklist in conversations
Send the questions in advance so the partner can bring evidence. Call a client who has worked with them for years, and visit the office where your team will sit.
Isatis works this way itself, with teams in Nijmegen and Sarajevo. We've been building software for more than 30 years, with 30+ engineers and more than 100 projects, and we're certified for ISO 9001 and ISO 27001. To hear our answers to these 15 questions, read about staff augmentation in Eastern Europe or book a conversation.
Frequently asked questions
What is a nearshore partner?
A nearshore partner is a software company in a nearby country that provides a dedicated team or individual engineers for your product. The engineers are employed by the partner and work in the same or a neighbouring time zone. You decide what gets built, and the partner takes care of the people.
How is choosing a nearshore partner different from choosing a software company?
The basics are the same: continuity, code ownership, and clear agreements. With a nearshore partner you add questions about working hours, language, travel, remote onboarding, the entity in the other country, and the transfer of intellectual property under local law.
How many overlapping working hours do you need with a nearshore team?
As many as possible. With a partner in the same time zone, such as a team in Sarajevo for a company in Western Europe, you share the whole working day, including standups and releases.
How do you check a nearshore partner's ISO 27001 certificate?
Ask for a copy and check four things: the entity's name, the scope including the team's location, the expiry date, and the certification body. You can ask that body to confirm the certificate is valid.
Can you take over a nearshore team later?
That depends on the contract. Agree up front whether and when you may take over engineers and how knowledge and access are handed over. A good partner discusses this openly.
