How to Vet an Offshore Development Agency

Most offshore engagements that fail do not fail because the developers were bad. They fail because the buyer could not tell, before signing, which kind of agency they were dealing with — and by the time the difference showed up, the code was on someone else's server and the money was spent.

This guide is deliberately written from your side of the table. It includes the questions that are inconvenient for agencies to answer, because those are the ones that actually separate a partner from a body shop. We are E-Cybertech Solution, an Indian software company that has been on the receiving end of this process since 2011 — and yes, you should run it on us too.

The standard process is: look at a portfolio, get on a call, compare three quotes, pick the middle one. Every step of that is easy for a weak agency to pass.

Portfolios are the least reliable artefact in the industry. Much of the work shown was subcontracted, or the agency built one screen of a larger product, or the client relationship ended badly and the case study was written anyway. Quotes are equally soft — a low number is not a commitment, it is an opening position, and the margin gets recovered later through change requests.

What actually predicts the outcome is observable behaviour under mild pressure: how they estimate something ambiguous, how they respond to a code review comment, what they do when you change your mind in week two. None of that shows up in a proposal. All of it shows up in a two-week paid trial, which is why Stage 5 matters more than Stages 1 to 4 combined.

1. The company legally exists, and you can prove it Find the registered entity, its registration number, and how long it has been filing. In India that means a CIN or LLPIN you can look up on the MCA portal; elsewhere, the local equivalent. Why: a surprising number of "agencies" are one freelancer with a website. That can still work — but you should know it, because it changes your bus-factor risk entirely.
2. Portfolio links are live, not screenshots Open every URL. Do the sites still exist? Do they look maintained? Search the client name and check the project was real. Why: dead links and screenshot-only portfolios usually mean the work is old, subcontracted, or was never shipped.
3. The team is visible somewhere public LinkedIn, GitHub, conference talks, an engineering blog. You are not looking for fame — just evidence that named humans work there. Why: an agency with 50 claimed developers and 4 findable employees is reselling someone else's bench.
4. Reviews exist outside their own website Clutch, GoodFirms, G2, Google Business Profile. Read the three-star reviews specifically — five-star reviews say nothing and one-star reviews are often disputes about scope. Why: the middle reviews are where you find the real texture: slipped timelines, communication gaps, what the recovery looked like.
5. Their own site is competent Does it load quickly? Is it secure? Is the content specific or generic filler? Does the same agency claim expertise in blockchain, AI, mobile, ERP, casino games and NFTs? Why: a development company's own website is the one project where they were the client. It tells you their standards when nobody is enforcing them.

The purpose of this call is not to explain your project. It is to find out how they think. Give them a deliberately under-specified brief and watch what they do with it.

1. Do they push back on your brief? A good partner will tell you which part of your plan is unnecessary, expensive, or wrong. A body shop will agree with everything. Why: an agency that never disagrees during sales will never disagree during delivery either — including when you are about to make an expensive mistake.
2. Can you talk to the actual developers? Ask to meet the engineer who would work on your project, not just the account manager. Ask them a technical question about your stack. Why: the gap between the polished salesperson and the actual team is the single biggest source of post-signature disappointment.
3. Is the assigned developer dedicated or shared? Ask directly: "Will this person be working only on my project, or are they split across clients? How many?" Why: "dedicated" is used loosely. A developer split across four projects will deliver roughly a quarter of what you are picturing, and every delay will be blamed on your requirements.
4. How do they estimate, and what happens when they are wrong? Ask for their last three projects: original estimate versus actual. Anyone who says they always hit estimates is either lying or not being asked hard problems. Why: the honest answer ("we were 30% over on two of them, here is what we changed") is far more reassuring than a perfect record.
5. What is the communication rhythm, in writing? Daily standup or async update? Which tools? What is the guaranteed response time during your working hours, not theirs? Why: vague answers here become 18-hour reply cycles later. Get the specific overlap window written down — see our US time-zone breakdown or the European overlap guide for what is realistic.
6. Who owns the project if your main contact leaves? Ask what happens if the assigned developer resigns mid-project, and what the handover looks like. Why: attrition is normal everywhere. An agency with a real answer (documentation standards, pair coverage, notice periods) has been through it. One that looks surprised has not.
7. Will they say no to something? Ask for something slightly unreasonable — a hard deadline, an unusual technology, a fixed price on a vague scope. Why: an agency that accepts an obviously unrealistic constraint to win the deal has just shown you exactly how it will handle the next one.

1. IP assignment is explicit and signed by individuals The contract must state that all code, designs and deliverables transfer to you. Critically, the individual developers must sign too, not just the company. Why: in several jurisdictions a contractor retains rights unless they personally assign them. A company-level clause alone can leave a gap.
2. Third-party and open-source components are declared Ask for a list of libraries, licences, purchased themes and API dependencies, with the licence type for each. Why: a GPL component or a single-site-licence theme buried in your codebase becomes your legal problem, not theirs, at exactly the wrong moment.
3. Payment is tied to verifiable milestones Never pay a large percentage up front. Tie payments to demonstrable, testable deliverables you can inspect in the repository. Why: a 50% advance removes the agency's incentive to move quickly and removes your leverage entirely.
4. There is a termination and handover clause Define what happens if you walk away: full code handover, credentials, documentation, deployment access, within a stated number of days. Why: this is the clause that decides whether a bad engagement costs you two months or your entire codebase.
5. Governing law and jurisdiction are named Which country's courts? Is arbitration specified? Where would a dispute actually be heard? Why: an unenforceable contract is a comfort blanket. Know before signing whether you would realistically pursue a claim — if not, weight the other checks higher.
6. Data protection matches your regime GDPR needs an Article 28 Data Processing Agreement plus Standard Contractual Clauses for transfers. India's DPDP Act adds its own obligations. Ask who the sub-processors are. Why: if the agency handles personal data of your users, their compliance failure is reported as your breach.
7. Rate changes and scope changes have a defined process How are change requests priced and approved? Can rates rise mid-engagement, and with how much notice? Why: this is where a low headline rate quietly becomes an expensive project. Get the mechanism in writing, not the promise.

1. The repository is yours from day one Code lives in your GitHub, GitLab or Bitbucket organisation. You add them, not the other way round. Why: this single check neutralises most of the catastrophic failure modes. If you can see daily commits from named developers, nothing can go badly wrong in silence.
2. Commits are frequent, atomic and attributed Ask to see the commit history of a recent project (with the client's permission). Look for daily commits from individuals, not weekly 8,000-line dumps from a shared account. Why: a single giant commit each Friday usually means work is being done elsewhere and pasted in — often by someone other than the developer you were introduced to.
3. Code review actually happens Are there pull requests with review comments, or does everything merge straight to main? Why: no code review means no second pair of eyes, which means the quality of your product is exactly the quality of one person's worst week.
4. There is a testing and QA position Automated tests, a QA person, a staging environment — any of these. What is their bug escape process? Why: agencies with no testing story ship faster in month one and slower forever after. Ask how they would handle a production bug at 2am your time.
5. Deployment and infrastructure are documented and in your accounts Your AWS, your DigitalOcean, your domain registrar. They get access; they do not hold the keys. Why: agencies holding hosting and domains is the most common form of soft hostage-taking, and it is entirely avoidable.
6. Ask them to critique their own past work "Show me a project you would build differently today, and tell me why." Why: engineers who cannot criticise their own older code have either not grown or are not being honest. Both are disqualifying.

Pay for one to two weeks of one developer — typically $600–$2,000 depending on region and seniority. Pick a real, self-contained slice of your product, not a toy exercise. You are not buying the deliverable. You are buying information.

1. Did the first commit land within 48 hours? Why: slow starts are almost never made up later. They usually mean the developer is finishing someone else's project.
2. Introduce a mid-trial scope change and watch On day 4 or 5, change something. Does it get absorbed, estimated calmly, or does it trigger a renegotiation? Why: your real project will change constantly. You need to know the reflex before you are committed.
3. Leave critical code review comments and see the response Reject a pull request for a legitimate reason. Is the response defensive, silent, or curious? Why: this is the single most predictive interaction in the entire process. You are going to do this a hundred times over the engagement.
4. Check the working hours actually match the promise Look at commit timestamps against the overlap window they committed to. Why: timestamps do not negotiate. If the promised 4-hour overlap is not visible in the git log during the trial, it will not appear later.
5. Read the code yourself, or have someone read it Even non-technical founders can check: are there comments? Meaningful names? A README that lets a new developer run the project? Why: this is what you are actually buying. If you cannot assess it, pay an independent engineer for two hours to review the trial output — it is the highest-return money in this entire process.

Any one of these justifies a hard question. Two or more together, and you should be walking.

Vetting runs both ways. An agency that qualifies you back is one that intends to deliver, because they are trying to establish whether the project can succeed at all. Be slightly suspicious of anyone who asks you nothing.

If they ask…	What it signals
"Who makes the final decision, and how quickly?"	They have been burned by projects that stalled waiting on an absent stakeholder. Good sign.
"What happens to your business if this ships three months late?"	They are calibrating real urgency versus stated urgency, so they can be honest about timelines.
"Has this project been attempted before?"	They want to know if they are inheriting a failed codebase — and they are right to ask.
"What is your budget range?"	Legitimate. Scope without budget is guesswork. Refusing to answer wastes everyone's time.
"Who will review our work on your side?"	They are checking whether feedback will arrive in usable form. A team with no technical reviewer needs a different engagement model.
Nothing at all	They are selling hours, not outcomes.

Do not average the 30 checks. They are not equally weighted, and treating them as a score lets a strong sales performance mask a fatal gap.

Tier	Checks	Rule
Non-negotiable	Repository ownership, IP assignment, termination & handover, paid trial accepted	Any failure ends the conversation, regardless of everything else.
Heavily weighted	Direct developer access, dedicated vs shared, code review, response to critical feedback	One weakness is survivable with mitigation. Two is not.
Informative	Portfolio depth, reviews, own website, estimation history	Use these to rank otherwise similar candidates.
Nice to have	Certifications, awards, office photos, team size	Weak predictors. Do not let these decide anything.

If two agencies pass the non-negotiables and the trial, pick the one whose response to your critical code review comment was most curious rather than most defensive. Over a two-year engagement, that trait compounds more than any rate difference.