Nearshore software development vendor checklist: 14 checks before you sign

Before you sign with a nearshore software development vendor, confirm three things in writing: who exactly will work on your code (named, senior engineers you have interviewed), when they will work (US business hours, including New York hours if that is where your team sits), and what happens to your code, access and team if the engagement changes or ends. Everything else on this checklist supports those three answers.

The 14-point nearshore vendor checklist

Copy this list into your vendor evaluation doc and ask every vendor to answer each item in writing before you sign.

1. Vetting process: the vendor can describe every stage of its technical screen, who runs it and what share of candidates pass.
2. Named engineers: you see the names and profiles of the specific people who will do the work, not sample resumes.
3. Your own interview: you can interview each proposed engineer on your stack before anyone starts.
4. Seniority defined: "senior" is mapped to a level you recognize (years, scope, a comparable big-tech level).
5. Working hours: the hours each engineer works are stated, and they overlap your core hours for standups, code review and incidents.
6. English and communication: you have heard each engineer explain a technical trade-off live, and you know who your day-to-day contact is.
7. NDA before profiles: the vendor will sign your NDA before sharing profiles or seeing your code.
8. Code and IP ownership: the agreement says you own all code and IP the engineers produce.
9. Access in your accounts: engineers work in your repos, cloud and tools, under accounts you control and can revoke at any time.
10. Device and security policy: the vendor can describe device requirements, MFA, secrets handling and offboarding.
11. Compliance experience: engineers have worked within the standards you are held to (SOC 2, HIPAA, PCI DSS), and the vendor can say where.
12. Pricing: rates per engineer per month are published or quoted in writing, with what is and is not included.
13. Replacement and exit: you know how an engineer is replaced, how fast, at whose cost, and how notice and handover work.
14. Onboarding and references: there is a written first-week plan with a concrete deliverable, plus references and case studies you can check.

If you are still deciding whether nearshore is the right model at all, start with nearshore vs offshore and onshore vs nearshore. This page assumes you have chosen nearshore and are now choosing a vendor.

Talent quality and vetting

The quality of the engineers is the whole product. Two vendors at the same price can send you people whose output differs several times over, so spend the most time here.

• Ask for the stages of the screen in order: sourcing, technical interview, live coding or system design, communication assessment, reference checks. Ask who runs each stage, a senior engineer or a recruiter reading a script.
• Ask what the screen tests for your stack. A generic algorithms test says little about whether someone can debug a flaky Kubernetes deploy or design a Postgres schema for your write load.
• Ask how AI tools are used in screening and whether humans make the final call.
• Ask for the pass rate and where the number comes from. A vendor that cannot explain its own funnel probably does not have one.

Seniority and named engineers before signing

The most common nearshore failure is the swap: the strong engineer you met in the sales process is not the one who shows up. Prevent it before you sign.

• Require named engineers, with profiles, before the agreement is final. Sample resumes or "engineers like these" are not enough.
• Interview each person yourself on a real problem from your codebase or a close stand-in.
• Pin down what "senior" means. A useful test: could this person own a service end to end, review others' pull requests and push back on a bad design without being asked?
• Ask who leads the team day to day if you are hiring several engineers, and meet that person too.

Time-zone overlap and working hours

Nearshore is worth paying for because of real-time collaboration: same-day code review, live debugging, joining your standups and incident calls. Make sure that is what you are buying.

• Ask which hours each engineer actually works, not which time zone they live in. Overlap only matters if the working day lines up with yours.
• Check the offsets yourself. Bogotá is UTC-5 with no daylight saving time, and Buenos Aires is UTC-3 with no daylight saving time, so their alignment with New York shifts slightly when US clocks change.
• Ask how on-call, releases and incident response are covered, and whether that is part of the engagement or extra.

Communication and English

• Hear each engineer explain a technical decision live, unscripted. Written English on a profile tells you little about how a design review will go.
• Ask how the engineers write: pull request descriptions, design docs, async updates in Slack. Ask for a sample if they have one they can share.
• Know who you escalate to if something goes wrong, and how fast they answer.

Security, access and IP

These are standard practice for any outside engineering team. A vendor that hesitates on any of them is a vendor to walk away from.

• NDA first. Get your NDA signed before you share architecture, code or data.
• Code ownership. The agreement should state that you own all code and IP produced for you, with no carve-outs for vendor "accelerators" you do not understand.
• Your accounts, your control. Engineers should work in your GitHub or GitLab org, your cloud accounts and your tools, under SSO and MFA you manage, with least-privilege roles. You should be able to revoke access in minutes.
• Devices. Ask about disk encryption, OS patching, endpoint protection and whether code may live on personal machines.
• Secure development. Ask how the team handles secrets, dependency updates and code review. The NIST Secure Software Development Framework (SP 800-218) is a useful neutral checklist to compare answers against.
• Offboarding. Ask what happens on an engineer's last day: access removal, device wipe and confirmation in writing.

Compliance experience

Separate two questions that vendors often blur. First, has the vendor itself been audited? A SOC 2 report is a CPA's report on a service organization's controls, so ask for the report, not a logo. Second, have the engineers worked within the standards your systems are held to? For payments work, that means PCI DSS, which applies to any organization that handles card data or can affect its security. For health data, it means HIPAA and your business associate obligations. Ask for specific examples: which systems, which controls, what they did differently because of the standard.

Pricing transparency

• Does the vendor publish rates, or is it quote-only? Published rates let you budget before the first call and compare vendors honestly.
• Is the price per engineer per month, per hour, or per project? Monthly per-engineer rates are the easiest to compare: total cost is team size times duration times rate.
• What is included: recruiting, replacement, account management, equipment, a team lead? What is extra?
• Does the rate change by seniority, and how is seniority decided? See Ryz rates by role and LatAm developer salaries for context on what senior talent costs in the region.

Substitution, replacement and exit terms

Nobody likes negotiating the ending at the start, but this is when you have the most say. Ask:

• If an engineer is not working out, how do I request a replacement, how fast does it happen, and who pays for the overlap?
• Can the vendor move one of my engineers to another client without my agreement?
• What notice do I need to give to reduce or end the team, and what notice does the vendor give me?
• What does handover look like: documentation, a knowledge-transfer period, access removal?
• If I want to scale up, how long does adding an engineer usually take?

Onboarding plan and first-week deliverable

A good vendor shows up with a plan. Ask for it in writing: who does what on day one (accounts, access, local environment), who on your side pairs with the new engineers, and what ships by the end of week one. A merged pull request to production code, even a minor fix, is the right bar. "Reading the codebase" for two weeks is not.

References and case studies

• Ask for case studies with outcomes you can check: what was built, for what kind of company, what changed.
• Ask for a reference call with an engineering leader, not a procurement contact, at a company with a stack and size close to yours.
• On the call, ask how long the team has been together, whether anyone was replaced and why, and what they would do differently.

Red flags vs green flags

Questions to ask and what a good answer sounds like

Where Ryz fits

Ryz runs nearshore software development and staff augmentation with senior engineers who work on your team, on US business hours, including New York hours. Only the top 1% of the tens of thousands of engineers we interview make it; the vetting process combines recruiter sourcing, structured AI interviews and recruiter review, with humans making the decisions. You get a scoped plan, a price and the names of the people who would do the work before anything starts, and you meet those engineers before the engagement begins.

Our rates are published: $7,000 to $15,000 per engineer per month, with mid-level engineers at $7,000 to $10,000, senior engineers at $10,000 to $15,000 and leads quoted per team. We'll sign your NDA before we share profiles, you own all code and IP our engineers produce, and engineers work in your accounts under access you can revoke at any time. Most of our engineers ship code in their first week. See case studies for production work.

Ryz is not the right fit if you want a self-serve freelance marketplace or hourly short gigs, or if you need engineers on European or Asian hours or follow-the-sun coverage.

Related

• Nearshore vs offshore software development
• Onshore vs nearshore software development
• How Ryz vets engineers
• Engineer rates by role
• LatAm developer salaries

FAQ

What should be on a nearshore software development vendor checklist?

At minimum: the vetting process, named engineers you interview before signing, stated working hours that overlap yours, live English communication, NDA, code and IP ownership, access in your own accounts, device and security policy, compliance experience, transparent pricing, replacement and exit terms, a first-week plan, and references.

What should I get in writing before signing with a nearshore vendor?

The names of the engineers, their working hours, the monthly rate per engineer and what it includes, a statement that you own all code and IP, how replacement and notice work, and the onboarding plan with a first-week deliverable.

Should I interview nearshore engineers before signing?

Yes. Interview each named engineer on a real problem from your stack. It is the most reliable way to stop the common swap where the person you met in sales is not the person who shows up.

How do I protect my IP with a nearshore development team?

Sign an NDA before sharing code, state in the agreement that you own all code and IP produced for you, keep all work in your own repos and cloud accounts under SSO and MFA you control, and have a written offboarding process that removes access on an engineer's last day.

Does a nearshore vendor need to be SOC 2 certified?

It depends on your requirements. If you need the vendor's own controls audited, ask for its SOC 2 report itself. Separately, ask whether the engineers have experience working within SOC 2, HIPAA or PCI DSS standards on systems like yours, with specific examples.

How much does nearshore software development cost?

It varies by vendor and seniority, so compare monthly rates per engineer in writing. Ryz publishes its rates: $7,000 to $15,000 per engineer per month, with leads quoted per team. Total cost is team size times duration times rate.

What is the biggest red flag in a nearshore vendor?

Refusing to name the engineers before you sign. If a vendor will only show sample resumes, you cannot judge the one thing that matters most: the people who will write your code.

Questions we didn't answer? Email info@ryzlabs.com.