How to Vet an Offshore Development Partner: The Questions That Actually Matter

The difference between a good offshore development partner and a bad one shows up in three places: how they handle the first disagreement, what happens when a key engineer leaves, and whether their estimates include the work you didn't think to ask about.

Every offshore vendor passes the surface-level test. The portfolio looks good. The initial call is professional. The proposal arrives on time. The problems emerge in month three when the honeymoon ends and the real working relationship begins. This vetting process is designed to surface those problems before you sign.

What should you look for before the first call?

Before talking to any vendor, check three signals that filter out 60% of the market.

Client retention over client count. A firm that lists 200 clients and has been operating for 5 years has an average engagement of 3–4 months. That's a project shop — build, hand off, find the next one. A firm with 30 clients over 8 years with an average engagement of 18+ months is retaining clients because the work is good enough to continue.

Specificity of case studies. "We built a mobile app for a healthcare client" tells you nothing. "We rebuilt the patient scheduling workflow for a 200-physician network, reducing appointment no-shows from 18% to 7% over 6 months" tells you everything. The level of detail in case studies reflects the level of involvement in the work.

Team page versus team reality. Check LinkedIn. Are the engineers listed on the website actually at the company? Do they have tenure? A firm where senior engineers have been there 3+ years has low attrition. A firm where the team page shows people who left 6 months ago is either inattentive or has retention problems.

What questions separate real partners from vendors?

The first call is a test — but you're the one running it. These questions are designed to reveal operational reality, not sales capability.

"Tell me about a project that went wrong and what you did about it." Every firm has had a project go sideways. The honest ones describe what happened, why, and what they changed. The dishonest ones claim 100% success rates or give a sanitised version where everything was the client's fault. A firm that can't describe a failure hasn't reflected on their work.

"What happens when a key engineer on my project leaves?" Attrition is real, especially in Indian tech markets where top engineers receive recruiters weekly. The answer should include: knowledge documentation practices that reduce key-person risk, a notice period that allows for transition (typically 60–90 days in India), and a backup resource who's already familiar with the project. If the answer is "that doesn't happen here," the firm hasn't thought about it.

"Walk me through how you estimate a project." Good estimation includes three things: what's in scope, what's explicitly out of scope, and what assumptions the estimate depends on. If the estimate is a single number with no breakdown, the firm either doesn't know how long the work will take or is deliberately hiding the detail.

"Can I talk to a current client — not a reference you've prepared?" Prepared references are useless. They've been coached. Ask to speak with a client who's been with the firm for 12+ months. Ask that client: "What's the most frustrating thing about working with them?" The answer reveals more than any sales deck.

How do you evaluate the technical team?

The technical evaluation matters more than the sales conversation. You're hiring engineers, not account managers.

Interview the actual engineers who'll work on your project. Not the CTO. Not the team lead who won't be coding. The people who will write your code. Ask them to walk through a recent technical decision — why they chose a specific architecture, what the tradeoffs were, and what they'd do differently next time.

Request a code review. Ask the firm to share a redacted pull request from a current project. The quality of code reviews reveals the engineering culture: are reviewers thorough or rubber-stamping? Are comments about correctness and maintainability or just style nits? Do reviews happen within hours or after three days?

Ask about testing practices. "We write tests" is insufficient. Ask: what's the test coverage target? Unit, integration, or end-to-end? Who writes the tests — the same developer or a separate QA engineer? How often do tests block a deployment? A firm that catches bugs before production has a testing culture. A firm that catches bugs in production has a fire-fighting culture.

Check the deployment process. "We deploy manually" is a red flag in 2026. CI/CD pipelines, automated testing on every PR, staging environments that mirror production, and rollback capabilities should be standard. If they're not, the firm is operating at a 2018 maturity level.

What red flags should disqualify a vendor immediately?

Some signals are clear enough to end the evaluation.

The sales team and the delivery team are completely separate. If the person who understands your project hands it off to someone who's never spoken to you, that handoff loses context. The person who scoped the project should be involved in the first month of delivery at minimum.

They won't share team composition until you sign. You have a right to know who will work on your project before committing. A firm that says "we'll assign the team after the contract" is keeping flexibility to put whoever is available on your project, not whoever is best.

The estimate comes back in 48 hours for a complex project. A serious estimate for a $100K+ custom system takes 1–2 weeks. The firm needs to understand your business, map the workflow, identify technical risks, and break down the work. An estimate that arrives in two days was produced from a template, not from analysis of your specific situation.

They resist signing an IP assignment agreement. Your code is yours. Any firm that hesitates on IP assignment is either planning to reuse your code for other clients or doesn't understand standard business practices. Walk away.

"We can do everything." A firm that claims expertise in mobile, web, AI, blockchain, IoT, AR/VR, and DevOps consulting is either massive (hundreds of engineers across dozens of teams) or lying. A 15–30 person firm that claims to do everything does nothing well. Look for firms that name their specific strengths and honestly describe their limits.

How do you structure a trial engagement?

The smartest vetting step is a paid trial. Not a free proof of concept — free work attracts the firm's B-team. A paid trial of 4–6 weeks where the vendor delivers a defined scope gives you the information no interview can provide.

Define a scope that's small enough to complete in 4–6 weeks but complex enough to test the firm's capabilities. A single feature or module from your larger project works well. The scope should include at least one integration, one architectural decision, and enough complexity to require daily communication.

During the trial, evaluate: communication quality (do they ask good questions early?), code quality (does the PR pass your review standards?), estimate accuracy (did they deliver what they said they would in the time they said?), and problem-solving (when they hit an obstacle, did they figure it out or wait for instructions?).

A trial engagement typically costs $5,000–$15,000. It's the cheapest insurance you can buy against a $100K+ engagement going wrong.

What does vetting look like from the vendor side?

Good firms vet clients too. If the vendor accepts every project without questions, they need the revenue badly enough to take bad-fit work. That desperation shows up in delivery.

When we evaluate a potential client at Madgeek, we ask: does this company have product management capability (or will we be guessing at requirements)? Is the engagement long enough to justify the onboarding investment? Is the decision-maker on the calls, or are we selling to someone who needs to sell internally? Does the project match our strengths?

We turn away work that doesn't fit. Sub-$30K one-off builds, projects without a clear product owner on the client side, and companies looking for the cheapest option. Not because the work is bad, but because the outcome won't be good for either party.

How does Madgeek handle the vetting questions?

We answer every question in this guide openly because the answers are our competitive advantage.

When a project goes wrong, we tell you about the eCommerce migration where we underestimated data migration complexity by 40%. It added three weeks. We absorbed the cost, restructured the migration approach, and the client has been with us for two years since. The failure taught us to scope data migration as a separate phase, which we now do on every project.

When an engineer leaves, the transition starts on day one of the notice period (60–90 days in India). Knowledge transfer is documented, the replacement engineer overlaps for 2–3 weeks minimum, and the client meets the replacement before the transition happens. We've had turnover — every firm does — and no client has lost a sprint because of it.

Our estimates break down by phase, by role, and by week. Every estimate lists assumptions and out-of-scope items. We include the work clients don't think to ask about — deployment setup, monitoring configuration, documentation — because discovering those costs mid-project is worse for everyone.

Every engineer is a full-time Madgeek employee. No freelancers, no subcontractors. You interview them before they start. Our founder is on every account, not as a gesture but as the technical lead who reviews architecture and joins weekly calls. Clutch rating: 4.8/5 across 50+ projects over 8 years.

That's what vetting should reveal. Not marketing polish — operational specifics from an offshore team that has nothing to hide.