How to Choose a Nearshore Development Partner: Process, Questions and Scorecard
Start with what you're buying, not who you're buying from
The most common reason a partner search goes wrong happens before the first vendor call: the buyer hasn't decided what they're buying. "We need a nearshore team" can mean three augmented React developers for your existing team, a dedicated cross-functional team that owns a product area, or a fixed-scope project. Each needs a different kind of vendor. If you're unsure which one fits, our guides on outsourcing models and dedicated teams vs staff augmentation will help.
Write a one-page brief before you contact anyone. It forces decisions on your side and gives every vendor the same input, which makes their answers comparable.
One-page partner brief: fill in before the first call
- The work: what the team will build in the first 3–6 months, in five sentences or fewer.
- Engagement model: staff augmentation, dedicated team or project. Who manages day to day?
- Team shape: roles, seniority, stack. For example "2 senior React Native, 1 mid backend (Node.js), 0.5 QA".
- Working hours: the overlap you need with named people, and in which time zone.
- Constraints: compliance (SOC 2, HIPAA, GDPR), data access, security requirements, on-site needs.
- Budget range and start date: a range is enough; it filters out mismatches early.
- Success after 90 days: what would make you renew? Shipped features, velocity, quality metrics, autonomy.
The selection process, step by step
A thorough process takes four to eight weeks. That feels slow when you needed the team yesterday, but switching vendors six months in costs far more: typically two to three months of lost velocity plus the handover. Here's the shape of it.
- Build the long list (10–15)Referrals from peers who've used a vendor for over a year are worth more than any directory. Add vendors from review platforms and curated lists such as our nearshore development companies roundup. Filter on the basics: your stack, your engagement model, a team size where you'd be neither their smallest nor their largest client.
- Send the brief and a short questionnaireTen questions at most: relevant projects, team availability, attrition, overlap hours, security certifications, pricing model. Vendors who answer with a generic deck instead of your questions tell you something already. For larger buys, a structured RFP makes the answers easier to compare.
- Shortlist calls (4–5)45 minutes each, with someone technical from the vendor, not only sales. Ask them to walk through a project similar to yours, including what went wrong.
- Deep evaluation (2–3)Interview the proposed engineers, call references, review the security setup and get a concrete team proposal with monthly cost. Our article on how to vet developers covers the interviews.
- Paid trial (1–2)Two to four weeks on a real piece of your backlog, scored against criteria you set in advance (details below).
- Negotiate and signNow you know what you're buying. Negotiate the terms that protect you: replacement, notice, IP, overlap hours.
The criteria that actually predict delivery
Every vendor claims great engineers, agile processes and excellent communication. The criteria below are the ones we've seen separate good engagements from painful ones, with what "good" looks like and how to check it without taking the vendor's word for it.
| Criterion | What good looks like | How to verify |
|---|---|---|
| Engineer quality | The proposed people solve your kind of problem with judgment, not just syntax | Technical interview with your engineers, a code walkthrough of their past work |
| Retention | Annual engineer attrition under ~15%, average tenure over 2 years | Ask for the number, then ask references how many people rotated on their team |
| Relevant delivery | Shipped products like yours, at your scale, and kept them running | Case walkthrough with the engineer who did the work; live product if possible |
| Communication | Raises problems early, writes clearly, pushes back on bad requirements | Give an ambiguous task in the interview and watch for questions |
| Overlap commitment | Named hours of shared time, in the contract | Ask what happens when someone wants to change hours |
| Process and QA | Clear definition of done, code review, test automation, dedicated QA | Ask for metrics: escaped defects, rework rate, how often QA sends tasks back |
| Security and compliance | Access control, device policies, SOC 2 or ISO 27001 where it matters | Security questionnaire, evidence of controls, a DPA if personal data is involved |
| Commercial terms | Fast replacement, fair notice, clean IP assignment, no lock-in | Contract review before the trial, not after |
Notice what's missing: hourly rate, company size and logos. Rate matters for budget, but within a country the difference between vendors is usually 10–20%, and a team that rotates engineers every four months costs more than that in lost productivity. If you want to compare costs properly, use the method in our nearshore rates guide: same team, same scope, monthly total.
On process metrics, ask for real numbers and how they're measured. At Gilzor, for example, we track how often QA returns a task to developers; it's about 5%. The exact figure matters less than whether a vendor measures anything like it at all.
Questions to ask, by conversation
Different people can answer different questions honestly. Salespeople can't tell you about code review culture; engineers can't tell you about contract terms. Use each conversation for what it's good for.
- Who exactly will work on our product, and can we interview each of them?
- What was your engineer attrition last year? How do you calculate it?
- If someone leaves, how fast do you replace them, and who pays for the ramp-up?
- Tell us about a client who left you. Why did they leave?
- What share of your revenue would we be? Who's your largest client?
- Where do the engineers actually live, and what hours will they work?
- Who on your side is accountable if delivery slips, and what do they do about it?
- Walk us through the last thing you shipped. What would you do differently?
- How do you handle a ticket that doesn't make sense?
- What does code review look like on your current project?
- When did you last disagree with a client, and how did that go?
- How long have you been with this company? Which projects before ours?
- Will you be on our project full-time, or shared with others?
- How long have you worked with them, and on what?
- How many people rotated off your team in the last year?
- Tell me about a time something went wrong. How did they handle it?
- Do they raise problems before you notice them?
- What would you negotiate differently in the contract?
- Would you hire them again for something important?
Ask the vendor for one reference who has worked with them for two years or more and one who ended the engagement. The second call is the more useful one.
- How is IP assigned from each engineer (employee or contractor) to you, and then to us?
- Which entity signs the contract, under which law?
- How do you control access to our systems and revoke it when someone leaves?
- Do you hold SOC 2 or ISO 27001, or can you meet our security questionnaire?
- What are the notice period, minimum term and exit handover terms?
- What is the fee if we hire one of your engineers directly?
Our software outsourcing contract guide lists the clauses to check in detail.
Built by Gilzor
Results we’ve shipped
Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.
Score your finalists
Rate each vendor 1–5 on every criterion after the deep evaluation, and again after the trial. Weights are set in favor of what predicts delivery: engineer quality counts most, commercial terms least. Three criteria are must-haves: a score of 2 or lower on engineer quality, retention or security flags the vendor whatever its total.
Partner scorecard: three finalists
1 = poor, 3 = acceptable, 5 = excellent. Score = weighted average scaled to 100. The best total is highlighted; a vendor flagged on a must-have should not win on total alone.
Fill this in with the people who'll work with the vendor every day, not only the person who ran the calls. When the scores differ by more than one point between your evaluators, talk about why before you average them. That conversation is often more useful than the number.
Run a paid trial project
A trial is where you stop evaluating how a vendor talks about work and start evaluating the work. We recommend it to every client, including ours.
- Pay for it. A paid trial gets the real team. Free "proof of concept" work tends to get the vendor's pre-sales stars, who then move to the next prospect.
- Use real work. Pick a self-contained slice of your backlog: a feature, an integration, a set of bugs with a refactor. It should touch your codebase, your CI and your people.
- Two to four weeks. Shorter shows only onboarding; longer turns into the engagement itself.
- Set the scoring in advance. Write down what you'll measure before day one, so the result isn't decided by mood.
- Run two vendors in parallel if the budget allows. Nothing calibrates expectations like a side-by-side comparison.
| Trial metric | How to measure | Good sign |
|---|---|---|
| Time to first merged PR | Days from access granted | Under 5 working days |
| Estimate accuracy | Actual vs estimated effort for trial tickets | Within ±25%, and they warn you early when it slips |
| Code review outcome | Your engineers rate PRs on readability, tests, fit with your patterns | Few rounds of review, comments get applied beyond the single line |
| Questions asked | Count and quality of clarifying questions in the first week | Several good questions early, few repeated later |
| Defects found after "done" | Bugs your team finds in trial work | Low, and fixed without debate |
| Communication | Written updates, standup quality, problems raised unprompted | You know the status without asking |
For a fuller measurement setup once the engagement runs, see staff augmentation metrics.
Red flags: how many have you seen?
Tick the ones you've encountered with a vendor on your shortlist. One flag is a question to ask. Several together is a pattern.
Vendor red flags
The rate flag deserves a word. Below-market rates aren't always a scam; sometimes a vendor is buying market share. More often the team is more junior than the CVs suggest, QA is missing, or engineers are paid below market and leave. We go deeper into this in why nearshore projects fail.
What changes with the partner's location
The process above works in any region. A few weights shift.
- Latin America (nearshore for the US): overlap is usually generous, so check where engineers actually live; regional remote hiring can mean a team spread over several countries. Test English with each person, not the account manager. In Mexico, ask for REPSE registration.
- Central and Eastern Europe (offshore with overlap): put the overlap window and any shifted hours in writing, and test written communication harder, because a bigger share of your collaboration will be async. Check GDPR-ready data processing terms if you share personal data.
- India and Southeast Asia (distant offshore): vendor quality varies most here, so the trial carries more weight. Ask how they handle clarification without overlap, and who on their side works your morning.
Whatever the region, the hardest part comes after signing. Plan the first 90 days with the same care as the selection; our guide on managing a dedicated development team covers that part.
FAQ
How do I choose a nearshore software development partner?
What questions should I ask a nearshore development company?
Should I do a trial project with a nearshore vendor?
What are red flags when choosing a nearshore partner?
How many vendors should I evaluate?
Is the hourly rate a good way to compare nearshore vendors?
Where Gilzor fits
We're a software development company in Poland and Cyprus, so for US clients we're an offshore partner with an agreed overlap window, not a nearshore one. We'd still encourage you to run us through every step above: interview the engineers we propose, call our references and start with a paid trial. Development starts within two weeks of signing, and 85% of our customers come back for more work.
See how our team extension works before the first call, and bring your scorecard.
No sales pitch
Get a straight answer for your project
Tell us what you’re building. We’ll reply with options, a rough cost and timeline. If we’re not the right fit, we’ll say so.
Co-Founder of Gilzor. Works with founders and product companies on how to staff and run engineering: team extension, dedicated teams, and getting stalled projects moving again.
Gilzor · Development Support partner
Need a team for your product?
Services
Development SupportTeam extension, maintenance, bug fixing, scaling.→By company type
Selected projects
The team behind them
