Your offshore developer isn't working out: the protocol to decide fast and not lose your quarter

A developer who isn't working out doesn't reveal themselves on day 1. The signs are gradual, often masked by politeness, distance, and your own desire for things to work. Here are the three categories of signals you need to monitor from the very first week.

This is the most objective signal, and yet the one we rationalise the longest. Your lead or senior developer spends more time reviewing, commenting on and correcting pull requests than they would gain by coding the feature themselves. Naming conventions aren't followed. Unit tests are absent or superficial. The code works but isn't maintainable. The distinction to make is simple: a developer in the onboarding phase produces correct but slow code. A developer who isn't working out produces code that needs to be rewritten. The difference is measurable within the first two weeks. If after fifteen days of full access to the repo, documentation and project tools, every merge request triggers a refactoring session, you don't have an integration problem. You have a skill-level problem. Quantify the ratio: time spent in review / time gained by the delivery. If this ratio exceeds 50%, the profile is slowing you down instead of speeding you up. That's the first decision threshold. To understand how to structure quality control protocols from the outset, read Externaliser son développement sans perdre en qualité : les protocoles qui séparent le code fiable du code jetable.

In the first few days, the developer asks questions. That's normal and even healthy. What's not normal: after two weeks, they still ask no relevant questions about the business, never rephrase an ambiguous ticket, and passively wait to be told exactly what to code, line by line. The other side of the problem: response times that keep growing. A Slack message sent at 9am that gets a reply at 2pm with no explanation. Stand-ups where the dev says "I'm making progress" without detailing what on. Daily reports that are empty or copy-pasted from one day to the next. These signals indicate either a lack of engagement, or a profile that is working for several clients in parallel — which is exactly the scenario you were trying to avoid by choosing a dedicated developer. A developer integrated into your team communicates like a member of your team. If after the first full sprint they still don't, things won't get better later. The problem doesn't come from the time zone difference (Madagascar is on the same time zone as France in summer, one hour apart in winter). The problem comes from the profile.

You've shared the documentation, granted access to Git, organised handover sessions, shared the SOPs. Yet every ticket requires a scoping call. Every feature comes back with a misaligned interpretation. Your team spends more time explaining than collaborating. The trap here is confusing patience with complacency. A developer who is competent on your technical stack gains autonomy visibly, week after week. Fewer questions on the same topics, spontaneous technical proposals, a progressive understanding of the business context. If this progression doesn't exist, you don't have a documentation problem (check SOP documentation équipe offshore : le format en 6 sections qui tue les questions répétitives et les erreurs de process to verify that your processes are clear). You have a profile that cannot reach the level required by your project. Set a clear milestone: by the end of the first month, the developer must be able to pick up a medium-complexity ticket and deliver it without an additional scoping call. If they can't, you have your answer.

Waiting until you have a developer who isn't working out before wondering what to do is too late. The guarantee is negotiated before signing. Here are the three contractual mechanisms that make the difference between a lost quarter and a two-week replacement.

Most offshore providers display a "replacement guarantee" in their terms and conditions. The reality is often different: vague timelines, no existing process, a replacement profile inferior to the first. What you must demand is a formalised evaluation period with objective validation criteria. At Taram, the logic is reversed. The developer is on a local permanent contract in Madagascar, and a structured trial period is built into the onboarding. If the profile doesn't work out according to criteria defined with you (code quality, autonomy, communication, meeting deadlines), the replacement is triggered at no additional cost. This isn't a commercial gesture. It's a contractual mechanism, because when you recruit a developer specifically for a client after technical tests and live coding, you own the outcome. What to check before signing: the exact duration of the trial period, the non-validation criteria, the guaranteed replacement timeline, and above all, whether the provider has a pool of available profiles or will have to restart a recruitment process from scratch.

A developer who leaves (or is replaced) without a handover means business context that disappears, undocumented architecture decisions, and a new dev who starts from scratch on entire sections of the codebase. This is the second loss of time, after the poor initial hire. Your contract must include a mandatory handover period between the outgoing and incoming developer. Even a short one (three to five days), this handover covers the critical points: project architecture, specific dependencies, unwritten code conventions, deployment workflow, and business context on modules currently in progress. If your provider doesn't include this handover, you will bear the full cost of the knowledge transfer alone. At Taram, the handover is a structured protocol: European management supervises the transfer, documentation is updated, and the new developer is assessed on their ability to pick up current tickets, not on theoretical exercises. See Passation de poste vers une équipe offshore à Madagascar : le protocole de transfert sans perte ni dépendance for the details of this protocol.

You've identified the signals. Your contract includes (or should have included) a replacement mechanism. What remains is the hardest part for an executive: deciding. Here is the decision framework that prevents you from losing another quarter.

Thirty days. That is the maximum timeframe to assess whether an offshore developer is working for your project. Not six months, not "after the next sprint", not "once they've settled in". Thirty days, with checkpoints at D+7, D+15 and D+30. At D+7, the developer must have delivered at least one complete ticket, even a simple one. You assess code quality, adherence to conventions, and communication. At D+15, they must be able to pick up a medium-complexity ticket without a detailed scoping call. The review/value ratio must show visible improvement. At D+30, they work autonomously on standard tickets and are beginning to contribute to technical discussions. If at D+30 you are still explaining the basics, correcting every delivery, or chasing for a reply, the decision is made. Don't let guilt ("maybe we didn't explain enough") or inertia ("restarting a recruitment is a hassle") cost you another quarter. The cost of a poor developer is not limited to their salary: it's the time of your internal team, the delay on your roadmap, and the energy of your best people diverted into technical babysitting.

The fear many executives have: "If I say the dev isn't working out, my provider will take it badly, and the rest of the collaboration will be difficult." This fear is legitimate if your provider operates like a traditional staffing firm, where replacement is seen as a commercial failure. With a structured provider, replacement is part of the process. You are not asking for a favour. You are activating a contractual clause. The right approach: factual, documented, unemotional. "Here are the deliverables from the past thirty days, here are the non-conformities against the criteria we defined together, here is the code review feedback. The profile does not match the required level. We are activating the replacement procedure." A provider who reacts poorly to this type of request gives you valuable information: you are not with the right partner. Taram treats replacement as a quality indicator, not as a problem. When recruitment is done on a tailored basis with client validation, replacement cases are rare. But when they do occur, the process exists and it works. To understand how the management of these situations is structured, see Manager un développeur à distance : les rituels, les outils et les erreurs qui coûtent six mois de roadmap.

A well-executed replacement doesn't cost you time. It saves you time compared to the scenario where you keep an unsuitable profile for six months. Do the math: three months with a dev producing at 30% of the expected velocity means 70% of capacity lost over a quarter. On top of which comes the time your team spends in review, corrections, and explanations. The right replacement means two weeks of transition for a developer delivering at 80% of their target capacity from the second month onwards. The cost of those two weeks is absorbed in less than one sprint by the difference in velocity. It also sends a strong signal to your internal team: you don't tolerate mediocrity, you don't sacrifice quality to avoid administrative discomfort. Your internal developers know that the offshore reinforcement is a real reinforcement, not an additional burden to carry. If you are in this situation today, or if you want to avoid finding yourself in it, the question is not "should I outsource or not". The question is "with which provider, and with what guarantees". Taram recruits your developer on a tailored basis, tests them on your stack, presents them to you before any decision, and assumes the replacement if the profile doesn't work out. One developer, one client, one dedicated infrastructure.