How to Vet a Dev Team Before You Sign

How to Vet a Dev Team Before You Sign

You've raised your round. Your product spec is ready. You need engineers, and you need them yesterday.

So you do what most founders do: Google "best offshore dev team," scroll past the ads, hop on two or three discovery calls, pick whoever seems sharpest, and wire 40% upfront.

Six months later, you're staring at a half-built app, a GitHub repo you don't own, and an agency that suddenly takes four days to answer a Slack message.

I've watched this play out dozens of times. I work with founders across the UAE, UK, and Australia who outsource their product builds. The ones who skip vetting pay for it twice — once for the failed build, again for the rebuild.

Here's the process I walk my clients through before they commit to any dev team.

Start with desk research. Don't skip it.

Before you even book a discovery call, spend 30 minutes doing basic homework.

Check their company registration. Is the business actually registered where they claim? In India, you can verify this on the MCA portal in under two minutes. For other countries, most have a public registry. If you can't confirm they legally exist, stop here.

Look at their portfolio — but actually click the links. A surprising number of agencies list portfolio projects with dead URLs, apps that were pulled from app stores, or sites that now belong to someone else. If their best work isn't live, ask why.

Find their developers on LinkedIn and GitHub. Not the sales team. The engineers. Do their profiles show consistent employment at this company? Do they have public commits? A team where nobody has a professional footprint online is a yellow flag.

Read their reviews on Clutch, GoodFirms, or Google — but read the negative ones first. Every agency has a few five-star reviews from friendly clients. The two-star and three-star reviews tell you how they handle problems.

The discovery call tells you more than they think

Here's what separates a real partner from a pitch machine: a good dev team will push back on you during the first call.

If you describe your product and they say "yes, we can do all of that, no problem" without a single question about your user base, your timeline constraints, or your technical stack preferences — that's your first red flag. A team that agrees with everything hasn't thought about anything.

Ask to speak directly with the developers who'd work on your project. Not the project manager. Not the account executive. The actual engineers. If the answer is "we'll introduce the team after signing," walk away. You're buying developer hours. You should be able to interview them before committing.

Ask bluntly: will these developers be dedicated to my project, or shared across clients? "Dedicated" is a word agencies throw around loosely. Pin it down. Get it in writing.

And ask this one: "Tell me about a project that failed or went badly. What happened and what did you change?" A company that claims zero failures either hasn't done enough work or isn't being honest with you.

The contract is where most founders get burned

IP assignment. This is the big one. Under U.S. copyright law, software doesn't automatically qualify as "work made for hire." You need an explicit, present-tense copyright assignment clause that covers all deliverables and takes effect the moment code is written — not conditioned on final payment.

If the contract says IP transfers "upon completion" or "upon full payment," you have a problem. If the project goes sideways and you terminate early, you could lose rights to everything that was built. Get your lawyer to look at this clause specifically.

Repository access from day one. Your code should live in your own GitHub, GitLab, or Bitbucket account from the first commit. If the agency insists on keeping the repo in their account and "transferring it at the end," that's a control mechanism, not a workflow preference. You should see every commit, every pull request, every branch — in real time.

Milestone-based payments. Never pay 40-50% upfront. Structure payments around inspectable milestones. "Design approval" is a milestone. "Backend API complete with passing tests" is a milestone. "Phase 1" is not a milestone — it's a calendar marker with no accountability attached.

Termination and handover. Your contract needs a clean exit clause: 30-day termination for convenience, with a 10-day window for full repository handover, credential transfer, and documentation. Without this, extracting yourself from a bad engagement becomes a hostage negotiation.

Governing law plus arbitration. A clause saying "governed by the laws of Delaware" means nothing if you can't enforce a judgment in India or Vietnam. You need binding arbitration through a named institution, seated in a country that's part of the New York Convention. Without that, your legal clause is decoration.

Run a paid trial. Always.

Before committing to a six-month engagement, run a paid trial. Two weeks, one developer, a real piece of your product scope. Budget $600-2,000 depending on seniority.

During the trial, watch for these specifics:

First commit timing. A competent developer who's actually available should push their first meaningful commit within 48 hours of kickoff. If the first week is all "environment setup" with zero visible output, the developer is either split across other projects or struggling with the stack.

Introduce a scope change mid-trial. Nothing dramatic — just shift a priority or add a small requirement. Watch how they handle it. Do they ask clarifying questions? Do they flag the timeline impact? Or do they just say "okay" and silently absorb it?

Leave a critical code review comment. Not a nitpick — a genuine architectural concern. A senior developer will engage thoughtfully, maybe push back with reasoning. A junior developer pretending to be senior will just make the change without comment.

Check their actual working hours against the overlap window they promised. If they committed to four hours of overlap with your timezone and you're consistently getting two, that pattern won't improve after you sign the full contract.

And have someone technical review the trial output. If you're a non-technical founder, spend $250-400 for an independent engineer to do a two-hour code review. Cheapest insurance you'll ever buy.

The red flags that should kill the deal

Some issues can be fixed in negotiation. These can't.

Code delivered as zip files instead of repo access. This means they don't want you seeing the work in progress. It also creates massive handover risk. Non-negotiable deal-breaker.

Rates below $12/hour. I'm all for cost efficiency — it's half the reason to outsource. But a senior full-stack developer in India bills $25-45/hour through an agency. At $12, you're getting a junior developer with a senior resume, or someone splitting their attention across four clients. The math doesn't work any other way.

All portfolio projects under NDA. Some NDA-protected work is normal. All of it? That means you can't verify a single past project. You're taking their word for everything.

The trial team gets swapped after signing. This is the classic bait-and-switch. You vetted Senior Dev A, you signed based on their work, and two weeks in they're "transitioning to another project" and you get Mid-Level Dev B. Your contract should include a key-personnel clause requiring written approval before any team changes.

They maintain your domain and hosting. Your DNS, your hosting accounts, your deployment pipeline — all of it should be in accounts you own with credentials you control. An agency that insists on managing your infrastructure is building dependency, whether they mean to or not.

What a good partner actually looks like

After vetting 50+ agencies for my clients, the pattern is consistent. Good teams share five traits:

They ask hard questions early. Before your second call, they've already flagged two things in your spec that don't add up.

They're transparent about limitations. "We're strong in React Native but we'd bring in a specialist for your ML pipeline" is a better answer than "we do everything."

They show you the humans. Named developers, LinkedIn profiles, GitHub contributions. No mystery bench.

They suggest a paid trial before you ask. A confident team wants you to see their work before you're locked in.

They've lost a client and can tell you why. The agencies that have never lost anyone either haven't been around long enough or are rewriting history.

The bottom line:

Vetting a dev team takes five to seven hours of focused work spread across two weeks. That investment saves you from a six-figure rebuild.

Don't pick a dev team the way you'd pick a restaurant. Pick them the way you'd pick a cofounder — because for the next 6-12 months, that's functionally what they are.

If you're evaluating offshore teams right now and want a second pair of eyes on the process, I do this for founders every week. Book a call and I'll walk through your shortlist with you.