Most people choose a software development outsourcing company on two things: the hourly rate and the portfolio page. Those happen to be the two least predictive signals you have access to.
The rate tells you almost nothing about total cost. A team at $30 an hour that needs three attempts to get a feature right is more expensive than a team at $70 that gets it right the first time, and you will not find that out until month four. The portfolio tells you even less. Portfolios show finished screens. They do not show whether the people who built those screens still work there, how much of it was rescued by a senior who has since left, or how the project actually went behind the case study.
So what does predict a good outcome? Mostly boring things. Whether you can name the individual who will write your code. Whether they will show you a real repository instead of a deck. Whether the contract says you own the source from day one. Whether anyone on their side is willing to tell you your idea has a problem.
We build software under other companies' brands, so we sit on the delivery side of this conversation several times a month. We see the briefs that set a project up to succeed and the ones that were doomed at the RFP stage. This is the vetting process we would run if we were the ones buying.
First, work out which kind of partner you actually need
"Outsourcing company" covers at least four business models that behave completely differently. Picking the wrong category is the most common early mistake, and no amount of good vetting inside the wrong category will save you.
| Model | You manage | Best when | Falls apart when |
|---|---|---|---|
| Staff augmentation | Individual developers, daily | You have a strong technical lead and need more hands | You have nobody senior in-house to direct the work |
| Dedicated team | Outcomes and priorities, weekly | Ongoing product work where continuity matters | Your scope is small or genuinely finite |
| Project-based delivery | Milestones and acceptance | You know what you want built and want one accountable team | Requirements are still moving weekly |
| Marketplace or freelancer | Everything, constantly | Small, well-defined, low-risk pieces of work | The work needs architecture decisions or continuity |
Here is the quick test. If you cannot name the person on your side who will make architecture calls and say yes or no to technical trade-offs, do not buy staff augmentation. You will be renting hands with nobody to point them anywhere. Buy managed delivery instead and pay for the judgment as well as the typing.
The five questions that do the most work
You can compress most of vendor selection into a handful of questions. Not because they are clever, but because weak teams cannot answer them cleanly and strong teams answer them without hesitating.
1. Who specifically writes my code, and can I meet them?
Ask for names, years of experience, and how long they have been at the company. Then ask to speak to them without an account manager in the room.
This one question kills more bad deals than anything else on the list. The pattern you are looking for is the bait and switch: you are sold by a sharp senior engineer, and then a junior you never met does the actual work while the senior appears for status calls. It is extremely common and it is the single biggest driver of the "the demo looked great, the delivery did not" story.
If the answer is "we will assign the best available resource once we begin," you are not buying a team. You are buying a queue position.
2. Can you walk me through a repository you built?
Not a screenshot. Not a Figma file. An actual codebase, shared live, with one of their engineers narrating it.
Obviously most client code is under NDA, so a good partner will offer an internal tool, an open-source contribution, or a sanitised sample. What matters is not the specific code. It is whether they can explain a decision they made, why they made it, and what they would do differently now. Engineers who have actually shipped things love this conversation. Sales-led shops try to redirect it.
Watch for whether they mention tests without being asked. It is a small tell and a reliable one.
3. What happens on day one after we stop working together?
Ask it exactly like that, early, and watch the room.
The answer you want is specific and unbothered: the code is in your organisation's repository the whole time, infrastructure runs in your cloud accounts, secrets are in your vault, documentation lives in your workspace, and here is the handover checklist we use. Some partners will send you their standard offboarding doc unprompted. That is a very good sign.
The answer that should worry you is any version of "we host that for you" applied to your source control, your production environment, or your domain. Convenience during the project becomes leverage at the end of it.
4. Tell me about a project that went badly
Every team with real mileage has one. A partner who cannot produce a single failure either has not shipped much or is not being straight with you.
The useful part is not the failure itself. It is what they changed afterwards. "The client kept changing scope" is a non-answer that blames the buyer. "We under-invested in discovery, shipped the wrong data model, and now we do a paid two-week technical discovery before quoting anything over a certain size" is a team that learns.
5. What would you push back on in my brief right now?
This is the best question on the list, and almost nobody asks it.
A partner worth hiring has already spotted something in your requirements that will cause pain. Maybe your timeline does not survive the integration you casually mentioned. Maybe the feature you described in one line is six weeks of work. Maybe you are asking for a mobile app when a responsive web build gets you to market in half the time.
If everything in your brief sounds great to them, they are either not reading it carefully or they are planning to bill you for the discovery of these problems later. You want the disagreement now, while it is free.
Red flags that are worth walking away over
Some warning signs are worth a conversation. These are worth ending one.
- A fixed price for a vague scope. If you handed over three paragraphs and got back a confident number for a six-month build, that number is fiction. It will be defended later through change requests, or through cutting quality where you cannot see it.
- No named engineers before signing. See question one. This does not improve after the contract.
- Their own IP clause covers your product. Some agreements quietly claim reusable components, frameworks, or "methodologies" that turn out to include large parts of what you paid for.
- Estimates with no ranges and no assumptions. Real estimates come with both. A single number with no stated assumptions means nobody did the thinking.
- They agree with everything. See question five. Enthusiastic agreement early is usually just politeness that becomes an invoice later.
- You cannot get a reference who had a problem. Anyone can supply three happy clients. Ask specifically for a client where something went wrong, then ask that client how the partner handled it.
The contract terms actually worth arguing about
Most people negotiate the rate and skim everything else. The rate is the least interesting part of the agreement. These four clauses decide how much freedom you have in a year.
IP assignment on payment, not on completion
You want ownership to transfer as work is paid for, incrementally. If ownership only transfers when the whole project is signed off as complete, then a dispute in month five means you have paid for five months of code you do not own. That is an uncomfortable position to negotiate from.
Source access from commit one
Your repository, your organisation, your admin rights. Not a zip file at the end of each phase. If you cannot see the commit history in real time, you cannot tell whether progress reports are true.
Named key personnel
Write the specific people into the agreement, with a clause requiring notice and approval before they are swapped out. This is the enforceable version of question one, and it is the clause that stops your senior engineer being quietly moved onto a bigger account.
An exit that does not need goodwill
Define notice period, what handover includes, what documentation you receive, and what it costs. Do this while everyone likes each other. A defined exit is not a sign of distrust, it is the thing that lets you stay relaxed for the rest of the relationship.
A scoring sheet you can actually use
If you are comparing three or four shortlisted companies, score them rather than going on feel. Feel favours whoever gave the best presentation, which is a measure of their sales function and not their engineering.
| What you are testing | Weight | How to score it |
|---|---|---|
| Named engineers, available to interview | High | Yes with tenure and a call, or no |
| Walked you through real code | High | Explained trade-offs, or deflected |
| Pushed back on your brief | High | Named a specific risk, or agreed with everything |
| Honest failure story with a change made | Medium | Specific and self-implicating, or blamed a client |
| Exit and handover defined in writing | High | Documented, or vague reassurance |
| Domain experience close to your problem | Medium | Shipped something structurally similar |
| Timezone overlap with your team | Medium | Hours of genuine overlap per day |
| Hourly rate | Low | Only compare after the above |
Notice that most of the high-weight rows are about transparency rather than skill. That is intentional. You cannot reliably assess someone else's engineering ability in a two-week sales process, but you can absolutely assess whether they are being straight with you. Transparency correlates with competence far more than credentials do.
Run a paid pilot before you run a project
The single most useful thing you can do costs a couple of weeks and a small fraction of the project budget. Hire your top choice for one real, self-contained piece of work first.
Not a free trial, and not a take-home test. A genuine paid piece of scope with a definition of done: one integration, one internal tool, one meaningful feature on an existing codebase.
What you learn in those two weeks:
- Whether the engineer you interviewed is the engineer who shows up
- How they communicate when something turns out harder than expected, which is the moment that actually matters
- What their code looks like when nobody is presenting it
- Whether their estimate held, and how they behaved when it did not
- Whether working with them is pleasant, which compounds over a year
A pilot costs a fortnight. Choosing wrong on a six-month build costs the six months, plus the rebuild, plus the market timing you lost. It is not a close call.
What to do this week
Vendor selection sprawls when you let it. Compress it.
- Decide your model first: augmentation, dedicated team, or managed delivery. One page, written down.
- Shortlist three. Not eight. Eight means you will compare on the only dimension that is easy to compare, which is price.
- Send all three the same brief, including one deliberately awkward constraint, and see who raises it.
- Run the five questions on every one of them. Score, do not vibe.
- Take references, and ask about a project that went wrong.
- Paid pilot with the leader. Then commit.
That process takes about three weeks and it removes most of the ways this decision goes badly. Compare that with the cost of finding out in month four that the senior engineer you liked has been on someone else's account since week two.
If you want the broader picture first, including the delivery models, real regional costs, and why these projects fail, start with our guide to outsourcing software development. And if you are trying to work out what any of this should cost, the offshore developer rate breakdown has the regional numbers.
