The short answer: six things to check

Choose a nearshore development partner on things you can verify before you sign, not on adjectives. Six checks cover most of the risk:

  1. Named clients. Case studies with the client's real name, and at least one reference you can call.
  2. Shared working hours. The team's working hours written down, not a promise of "overlap".
  3. Days to start. How many business days from a signed contract to an engineer's first day.
  4. Replacement terms. What happens, and who pays, when an engineer is not working out.
  5. Code ownership. Full intellectual property assignment to you, from day one.
  6. How it ends. The notice period, the minimum term, and what a handover includes.

Every one of these has a concrete answer. A partner that can give it to you in writing is telling you how the engagement will actually run. A partner that answers with "flexible" or "it depends" is telling you something too.

Six criteria, and how to check each one

1. Clients you can name and check

Any partner can say it has worked with startups and enterprises. What matters is whether it publishes who. A case study that names the client, says what the partner built and says how long the work ran is a claim you can check against the product itself.

How to check it: look for case studies with real client names, not "a leading fintech company". Ask for one reference from an engagement similar to yours, and ask how long the longest client relationship has lasted. Length is the hardest thing to fake: clients do not stay for years with a partner that does not deliver.

2. How much of your working day the team shares

Shared hours decide how fast a question gets an answer, whether a production issue is fixed the same day, and whether the engineers can join your standup. "Good overlap" means nothing until it has a number.

How to check it: ask for the team's working hours in writing, in their time zone and in yours, and whether those hours apply to every engineer or only to a lead. If you are still deciding between regions, our nearshore vs offshore comparison sets the hours side by side.

3. How many days until an engineer starts

Speed to start is the reason most companies look for a partner instead of hiring. It depends on one thing: whether the profile you need is already on the partner's bench or has to be recruited.

How to check it: ask for two numbers in business days, one for a profile on the bench and one for a profile that has to be found. Then ask whether you can interview the candidates and choose who joins. A partner that knows its bench answers both on the first call.

4. What happens when someone is not working out

Sooner or later one engineer will not be the right fit. The question is not whether the partner replaces them, every partner says yes, but how the handover works and who pays for it.

How to check it: ask how many days the outgoing and incoming engineers overlap, and whether you are billed for both during that time. The answer should be in the contract, not in a sales conversation.

5. Who owns the code, from day one

You should own everything created for you: code, designs, data models, documentation. Some contracts only transfer ownership on final payment, or leave parts of the work under the partner's license.

How to check it: read the intellectual property clause before you sign. Look for a full assignment of everything created, with no condition attached, and a clear license for anything the partner brings that it built before working with you.

6. How the contract ends

The way an engagement ends says more about a partner than the way it starts. Long minimum terms and heavy exit penalties protect the partner. Short notice periods and an ordered handover protect you.

How to check it: ask for the minimum term, the notice period on each side, and what a handover to your in-house team includes. Then ask for an example of a client that took the work in house. Our FAQ covers the questions worth asking before signing.

Staff augmentation, dedicated team or full-cycle product development

Before you compare partners, decide which model you are buying. The simplest test is who directs the work day to day.

  • Staff augmentation: engineers join your team and you direct them. It fits when you already have an engineering organization and need more capacity. It is the wrong model if nobody on your side has time to direct the new people. TenFore Golf is an example: engineers joined its team to modernize its employee app, its customer app and its self-service kiosk.
  • Dedicated team: the partner runs a cross-functional team that owns a product or a workstream, and you set the priorities. It fits when you need a whole team, not a few seats. It is the wrong model for a gap of one or two people, or when nobody prioritizes the backlog. Milc is an example: a nine-year engagement in which the team grew to 40 people.
  • Full-cycle product development: the partner takes a defined product from concept to launch and is accountable for the result. It fits when you know what you need built and do not have a team to build it. It is the wrong model when the scope still changes every week, because every change becomes a negotiation. WageWatch is an example: an app built from scratch, from the mobile app to the backend and the admin portal.

The pages on staff augmentation and dedicated teams go deeper into how each one works and when it is the wrong answer.

How CodigoDelSur answers the six checks

CodigoDelSur has built software for companies in the United States and the rest of the world since 2007. We are based in Montevideo, Uruguay, with a team of about 140 people. These are our answers to the six checks, the same ones we put in the contract.

  1. Named clients. More than 250 clients, and every case study in our portfolio names the client and says what we built. We worked with Grubhub for close to four years, with an embedded team that grew to 15 engineers. Our first client, from 2007, is still a client today.
  2. Shared working hours. Every engineer works 10:00 to 19:00 Uruguay time, hours chosen to overlap with both United States coasts. Why we build from Uruguay explains the rest.
  3. Days to start. One business day when the profile is on our bench, five business days when we recruit. You see each candidate's CV and can interview all of them.
  4. Replacement terms. If an engineer is not working out, the replacement comes with ten business days of overlap that are not billed.
  5. Code ownership. Full assignment of the intellectual property to the client, with full title guarantee, over everything we create.
  6. How it ends. Two weeks' notice to modify or end an engagement, on either side, and a minimum term of one sprint. Milc is how a long engagement ends well: after nine years, an ordered handover to the client's in-house team.

Frequently asked questions

What should you look for in a nearshore development partner?

Six things you can verify before signing: named clients, the team's working hours in writing, how many business days until an engineer starts, replacement terms, full ownership of the code from day one, and how the contract ends.

How can you check a nearshore partner's clients before signing?

Look for case studies that name the client and say what the partner built, then ask for a reference from a similar engagement. Ask how long the longest client relationship has lasted: clients do not stay for years with a partner that does not deliver.

Is a nearshore development partner the same as a staffing agency?

No. A staffing agency places individual people and the work stays yours to run. A development partner can also run whole teams or build a product end to end, with design, engineering and QA in house.

How many nearshore partners should you talk to before choosing one?

Two or three, compared on the same six checks and in writing. More than that usually slows the decision without adding information.

Should you start with a short trial before committing to a nearshore team?

Yes, if the partner allows it. At CodigoDelSur the minimum term is one sprint, two weeks, so the first sprint works as a trial with real work instead of a test project.

Can you switch from staff augmentation to a dedicated team later?

Yes. Many companies start with one or two engineers inside their team and move to a dedicated team once the work needs its own owner. At CodigoDelSur changing the engagement takes two weeks' notice.

What does a good handover look like when a nearshore engagement ends?

Planned in advance, with documentation, access and knowledge transferred to your in-house team while both teams still overlap. Milc ended a nine-year engagement with CodigoDelSur this way.

‍