Most nearshore projects are decided on paper. A rate card, a few references, a visit to the offices in Casablanca or Rabat, then a multi-year commitment and a full team from day one.

That is the opposite of how executives treat any other risky investment. You do not launch a product without testing it. You do not hire a director without a probation period. A team abroad deserves the same caution.

Our recommendation is simple: before you sign for a team, sign for a pilot. Three months, a real scope, criteria written in advance. At the end, you decide on facts.

Why the proposal is not enough

A tender answers one question: "who offers the best price for what I described?" It does not answer the questions that make a nearshore project succeed or fail.

  • Does your organisation know how to give work to a remote team?
  • Are your specifications clear enough to be understood without you in the room?
  • Can the on-site lead say no, or do they say yes to everything?
  • Are the profiles in the proposal the people who will actually work on your project?

None of these answers is in a sales proposal. They surface within a few weeks of real work. The pilot exists to get them before the commitment becomes heavy.

There is another reason, less comfortable. The pilot also tests your own house. Part of nearshore failures come from the client side: priorities that change every week, an internal contact who is never available, decisions that keep escalating. Better to find out with three people than with twenty.

What a pilot is not

A pilot is not a demo. If you give the team a small, isolated topic, with nothing at stake and no contact with your systems, it will succeed, and you will have learned nothing.

A pilot is not a free trial either. A provider working for free puts whoever is available on your project, not whoever is good. Pay for the pilot at the normal rate. That is the price of reliable information.

Finally, a pilot is not a disguised commitment. If the contract states that the full team starts automatically after three months, it is not a test. The decision to continue must be real, and so must the option to stop.

How to frame it

1. A real scope, kept small

Pick something that matters: a feature people are waiting for, a real processing flow, part of your support. It must touch your tools, your data and your people. That is where the difficulties show up.

In terms of size, a small team is enough: two to four people, including the future on-site lead. That last point is essential. If the local manager is not part of the pilot, you are testing individual contributors, not an organisation.

2. Criteria written before day one

This is the step almost everyone skips. Before the first day, write down on one page what will make you say "we continue" or "we stop". For example:

  • Delivery: are the commitments made at the start of each cycle met?
  • Quality: how many returns or fixes after delivery?
  • Autonomy: how many questions escalate that could have been settled on site?
  • Communication: are problems flagged early, or discovered late?
  • Stability: are the people introduced at the start still there at the end?

Thresholds depend on your business. What matters is that they are set in cold blood. At the end of a pilot, everyone wants it to work, and criteria written after the fact are always met.

3. An available internal counterpart

Pilots often fail for lack of a counterpart on the home side. Appoint someone who genuinely spends time with the team: answering, explaining context, approving. If nobody has that time for three months, the problem is not nearshore. It is the timing.

4. Checkpoints

Three meetings give a 90-day pilot its structure:

  • End of month one: is the team set up, does it have access to everything, has it delivered something?
  • End of month two: has a rhythm been found, are the criteria moving in the right direction?
  • End of month three: review against the written criteria, and decision.

Each checkpoint takes an hour, with both sides present. You discuss facts, not impressions.

Reading the results

A pilot does not always give a yes-or-no answer. There are three possible outcomes.

The criteria are met. You scale up, but gradually. You add people in waves, keeping the pilot lead as the backbone of the larger team.

The criteria are partly met. This is the most common case, and the most instructive. Look at where the gap comes from. If it is a profile, replace it. If it is your organisation, fix it before going further. If it is the model itself, ask the question openly.

The criteria are not met. You stop, and you have lost three months and a limited budget, instead of two years and an entire team. That is exactly what a test is for.

In all three cases, you now know what remote work really costs your company. You did not have that information before, and it remains valid whatever partner you choose next.

Prepare what comes next during the pilot

A good pilot already prepares the scale-up. Three topics are handled during the 90 days, not after.

  • The target model: subsidiary, provider, or a hybrid. The pilot shows you which one fits the way you work.
  • Decision rights: what is decided on site, what escalates. The pilot puts them to the test on a small scope.
  • Reversibility: documentation, access, ownership of code and data. If it is not in place for three people, it will not be for thirty.

In short

Nearshore in Morocco works. The talent is there, the proximity is real. But it works for companies that know how to work with a remote team, and the only way to find out is to try.

Three months, a real topic, criteria written in advance, a decision at the end. It is less spectacular than a launch with twenty people. It is far safer.

Considering a team in Morocco and want to frame a pilot before committing? Write to us: that is often where we start.