Choosing a nearshore partner: 15 questions to ask first

A practical evaluation guide for founders, CTOs and engineering managers comparing nearshore providers. Fifteen questions, what a good answer looks like, what should worry you, and a scorecard to line providers up side by side.

Most first calls with a nearshore provider revolve around the rate and how fast someone can start. Fair questions, but they tell you little about what working together will feel like a year from now. The problems I see in practice almost always start in places nobody asked about upfront: who actually employs the developer, what happens when someone drops out, and who owns the code when you stop.

This guide helps you compare providers on the same points. It does not explain what nearshore is or what it costs. That is covered on nearshore developers and in what a nearshore developer costs in 2026. Still weighing the location itself? Start with nearshore versus offshore development.

For each question you get why it matters, what a clear answer contains, which answer is a red flag, and briefly how we handle it. That last part is deliberately short. tre plus does not need to win every question, and in some situations a different setup simply fits better.

First: does nearshore fit your situation at all?

Before you compare providers, check whether the model suits you. In these five situations I usually advise against it, including with us.

Nobody on your side can give technical direction day to day. A developer who works inside your team needs someone to set priorities, answer questions and review code. Without that person, even a strong engineer ends up waiting.

You want to hand over a scoped project with delivery responsibility. Then you need a project agency with a fixed scope, not a developer who joins your team.

You need help for a few weeks. Selection and onboarding take time. For short, specialist work a freelancer is often the better call.

You are only looking for the lowest possible price. Then you will mostly compare rates, and the questions below matter less to you than to someone building a team that stays.

There is no time for onboarding, documentation or code review. Anyone coming in from outside needs context. If nobody can give it, it goes wrong, however good the developer is.

If none of this sounds like you, the fifteen questions below will help you compare providers fairly.

Model and people

1. Who is the developer's legal employer?

Why it matters: the employer sets the terms of employment, shapes loyalty and affects how long someone stays. It is also the party responsible for payroll and local obligations.

A clear answer names the legal entity, the country and the type of contract. For example: the developer is permanently employed by the provider's local entity.

Red flag: vague answers such as 'we work with a network', or a freelancer passed through without that being made clear upfront.

At tre plus we handle the local employment, payroll, office and local support for assigned developers. You direct the actual work.

2. Is the capacity dedicated or shared?

Why it matters: a developer switching between three clients builds less context and is less available when you need them.

A clear answer puts the agreed capacity, working days and availability in the SOW. For full-time work, the provider confirms explicitly whether the developer works only for you. For part-time work, it is clear how the rest of the time is filled and how possible conflicts of interest are handled.

Red flag: 'full-time' without anything in writing that defines it, or no answer to who the developer works for during the rest of the week.

At tre plus the assigned capacity is set out in the SOW.

3. Where does the developer actually work?

Why it matters: an office with colleagues, support and a stable connection produces different results than scattered individuals working from wherever.

A clear answer names the city, whether there is an own office and what the remote-work policy is.

Red flag: an address that turns out to be a mailbox, or reluctance to show you the office.

At tre plus developers work from our own office in Pristina, inside your tools and your codebase. More about the region on hire developers in Kosovo.

4. Who selects, interviews and decides?

Why it matters: if the provider alone chooses, you get someone who fits their bench rather than your team.

A clear answer describes the provider's pre-selection and leaves the final decision with you. You hold your own interview and you can say no.

Red flag: you are shown one name without your own interview, or you only learn who is coming after signing.

At tre plus you see suitable profiles within seven working days, and you decide who to continue with.

Quality and direction

5. How is technical quality assessed?

Why it matters: a CV says little about how someone will work in your codebase.

A clear answer explains what the provider tests, who does the testing, and how much room you have for your own technical interview or practical exercise.

Red flag: 'all our developers are senior' with no explanation of how that was established.

At tre plus we select on technical skills and on communication before you see a profile. After that, you assess in your own way.

6. Who owns the roadmap, backlog and code reviews?

Why it matters: this decides whether you get a colleague or an external delivery channel. Both exist, but they are different models.

A clear answer says who sets priorities, who reviews and who you talk to when things are not working.

Red flag: a provider-side project manager sitting between you and the developer, when what you want is someone inside your own team.

At tre plus you keep the roadmap, the reviews and the technical direction. Whether one developer or a small team with a tech lead fits better is explained on Developer as a Service, Team as a Service and in the staff augmentation versus dedicated team comparison on our services page.

7. How do onboarding, travel and on-site collaboration work?

Why it matters: the first weeks decide how quickly someone really contributes. A visit in either direction often does more than ten calls.

A clear answer describes the onboarding and agrees frequency, purpose, planning and cost of travel upfront.

Red flag: 'travel is included' without anyone being able to say what, when or how often.

At tre plus travel and on-site onboarding are agreed per client and per engagement. Expect two to four weeks of onboarding before someone is fully up to speed.

Contract and risk

8. Who owns the code and the intellectual property?

Why it matters: if you stop one day, you want to be sure you can keep using everything that was built for you.

A clear answer says that client-specific work, such as code, documentation, configurations and designs, is assigned to you under the agreement. It also states the conditions, for example that transfer depends on full payment, and the exceptions: the provider's existing tools, general methods and previously developed IP.

Red flag: nothing about IP in the contract, or a promise that 'everything' is yours with no exceptions. The second sounds good, but it is rarely what the legal text actually says.

At tre plus client-specific work is assigned to you under the agreement, with the exceptions set out there.

9. How are privacy, data processing and security handled?

Why it matters: a developer gets access to your systems and sometimes to personal data. Who is responsible for what needs to be clear before that happens.

A clear answer shows who is the controller and who is the processor, whether a data processing agreement is needed, which systems and data are accessible, and how access, logging, confidentiality and revoking access are arranged.

Red flag: 'we have never had a problem with that' instead of a concrete answer.

At tre plus these arrangements are set per client and per agreement, to match your systems and data.

10. What happens with illness, departure or underperformance?

Why it matters: this is when you find out what a provider is really worth.

A clear answer explains how short and long absences are handled contractually, when a replacement search starts, what effort the provider commits to and how invoicing works during that period.

Red flag: a replacement 'guarantee' that appears nowhere in writing. Or the opposite: nobody knows what happens.

At tre plus the exact arrangements are in the MSA and the SOW. There is no unlimited replacement guarantee; when someone drops out, we actively look for a suitable replacement.

11. What does the monthly fee include, and what not?

Why it matters: two rates are only comparable once you know what is in them.

A clear answer lists what is included, such as recruitment, employment, workplace and support, and what is billed separately. One-off costs are named upfront.

Red flag: a low hourly rate with unclear extras for recruitment, equipment or management.

At tre plus we work with a fixed monthly fee. What it includes and what each level costs is explained in what a nearshore developer costs in 2026.

12. What is the minimum term, and when can you exit?

Why it matters: a start that is too short gives nobody time to land, while a long lock-in with no way out is a risk.

A clear answer names the initial period, how renewal works, and when and how you can stop.

Red flag: 'cancel monthly' in the sales pitch and something very different in the contract. Read the terms yourself.

At tre plus an engagement usually starts with six months. After that it continues for as long as it works. Stopping happens at the end of an agreed period, with reasonable notice under the agreement.

13. Can you hire the developer directly later on?

Why it matters: sometimes a collaboration works so well that you want to bring someone in-house.

A clear answer says whether this is possible, from when, and which conversion fee or conditions apply. Check this before you sign, not when it comes up.

Red flag: an absolute ban, or conditions that only surface once you ask.

At tre plus a direct hire can be discussed under the terms of the agreement.

Proof and continuity

14. How are equipment, workplace and continuity arranged?

Why it matters: a broken laptop or a power cut should not stall your sprint.

A clear answer says who supplies the equipment, how it is secured and what happens during outages. Specific hardware or client-managed devices are agreed upfront.

Red flag: 'the developer sorts that out themselves'.

At tre plus we organise the office, the workplace, local support and the equipment. Security requirements, specific hardware and devices you manage yourself are agreed with you upfront.

15. What verifiable client proof exists?

Why it matters: every provider has good stories. You want one you can check.

A clear answer is a published case with a real client name and a contact you can speak to, or a reference you can call yourself.

Red flag: only anonymous logos or unnamed quotes, and no reference on request.

At tre plus our published case is DutchDrops, a Shopware environment. Ask every provider for a case close to your own situation, and be critical if there is none.

Scorecard: line providers up side by side

Take this table to your calls. For each question and provider, pick one of three ratings: clear, unclear or red flag. Use the last column for a short note, for example where in the contract the answer sits.

At the end, do not just count red flags. Look at the questions that weigh most for your situation. For a scale-up without its own tech lead, question 6 matters more than for a team with a strong CTO.

Common mistakes when comparing

Comparing on rate alone. A lower rate means nothing if recruitment, equipment or replacement are billed separately. Compare what is included.

Trusting the sales pitch without reading the contract. What is said on a call only counts once it is in the MSA or SOW.

Skipping your own technical interview. You will be working with this person. Take the time to assess them yourself.

Forgetting your own side. Most collaborations do not stall on the developer, but on the lack of someone who directs, reviews and provides context.

Finally

A good nearshore partner can answer every question in this guide concretely and show you where it sits in the agreement. If a provider falls short on a few points, that is not a disaster, as long as you know upfront.

Want to put these questions to us? Please do. See how we work on dedicated developers, or book a call.