60+ Questions to Ask When Outsourcing Software Development (and What the Answers Should Tell You)
Key takeaways
Most vendor evaluations fail not because companies ask bad questions, but because they ask too few, too late, and never decide in advance what a good answer sounds like.
The questions that matter sort into six areas: company stability, security and IP, team and talent, delivery process, commercial terms, and how the vendor uses AI.
A strong vendor welcomes hard questions and answers with specifics. Vague, defensive, or rehearsed answers are a signal, not a coincidence.
Staff augmentation and full project outsourcing need different questions. Asking the project-outsourcing set when you actually want individual developers will mislead you.
The differentiator in this guide: it tells you what the answers should sound like, and which answers should end the conversation.
Most question lists tell you what to ask. Almost none tell you what the answers should sound like. So you walk into a discovery call with 15 good questions, the vendor answers all of them smoothly, and you still have no idea whether you just talked to a reliable partner or a sales team that has heard those questions a hundred times.
This guide fixes that. After each cluster of questions, you get a short note on what a strong answer sounds like, and what answer should make you cross a vendor off your shortlist.
Why most vendor vetting falls short
Evaluating a software development vendor's reliability depends on company stability, team continuity, security posture, and contractual clarity. The most common failure in vendor selection is not asking too few questions, but asking surface-level questions and accepting surface-level answers, then discovering hidden turnover, vague service levels, or missing IP clauses three months into the engagement.
If you're like most engineering and product leaders evaluating an outsourcing partner for the first or second time, your discovery call covers maybe five or six things. Do you have experience in our industry. What's your tech stack? How much do you charge? Can we see a portfolio? References?
All reasonable. All easy for any competent sales team to answer well.
The problem shows up later. The senior developer you were sold on rotates off after the first sprint, replaced by someone the vendor "is confident will ramp up quickly." The status reports are a wall of green that says nothing. Scope creeps, and every change triggers a negotiation you didn't budget time for. And when you finally read the contract closely, you realize the IP assignment language is thinner than you assumed.
None of this is exotic. It's the predictable result of an evaluation that tested whether the vendor could answer, not whether the answer was good.
A structured approach changes that. You decide, before the call, which answers you'll accept and which are deal-breakers. You ask follow-up questions that a rehearsed pitch can't survive. And you treat the discovery call as the first sample of what working with this team will feel like, because it is. If the answers are muddled and evasive now, when the vendor is trying to win you, that's the best the relationship will ever look.
How to use this list
A vendor evaluation question list works best as a scorecard, not a checklist. Buyers should weight categories by their own risk profile, lead first calls with the highest-stakes questions, and reserve detailed process and commercial questions for a second deep-dive session with shortlisted vendors only.
You don't need to ask all 60-plus questions on the first call. You'd exhaust everyone and learn less, not more.
Here's the triage. Group the questions into six categories: company stability, security and IP, team and talent, delivery process, commercial terms, and AI practices. On a first call with three or four vendors, lead with company stability and the one or two security and IP questions that would disqualify a vendor outright. That's your filter. It cuts the field fast.
Then run a deep-dive session with the two or three vendors who survive. That's where the team, process, and commercial questions earn their place, because by then you're not screening, you're choosing.
Treat the whole thing as a scorecard. Weight the categories by what actually puts your project at risk. If you're handling regulated health or financial data, security and IP carry more weight. If you've been burned by knowledge loss before, team stability does. Score each answer, not just whether you got one.
Company stability and credibility
Evaluating a software development vendor's company stability involves examining company age, ownership structure, client retention patterns, security certifications, and the maturity of the regional IT industry the vendor operates in. Vendors with ISO 27001 certification have passed third-party auditing of their information security management system, a stronger signal than self-reported claims of being "experienced" or "trusted."
This category answers one question: is this company going to be around, and stable, for the length of your engagement?
A vendor's stability shows up in numbers it can verify, not adjectives it chooses for its homepage. Ask for the numbers.
Questions to ask:
What year was the company founded, and who owns it now?
How many full-time employees do you have, and how many are engineers versus sales and admin?
What's your client retention rate, and what's the average length of an active client relationship?
Can you name three clients you've worked with for more than two years?
Which security certifications do you hold (like ISO 27001), and when were they last audited?
What's your rating and review count on Clutch or GoodFirms, and can we read the full reviews?
Have you had layoffs or major restructuring in the last two years?
How may active projects do you have right now?
That last one matters more than it looks. A vendor that makes 70% of its revenue from three clients is one lost account away from a crisis, and you don't want to be there when it happens.
On certifications, know what you're asking about. ISO 27001 is the international standard for an information security management system; a certified vendor has passed an audit by an accredited body.
Clutch is worth a specific mention. It's the standard B2B review platform for software vendors, and reviews there are verified through client interviews, which makes them harder to fake than testimonials on a vendor's own site. Read the full reviews, not the star rating. The detail in a four-star review usually tells you more than the headline on a five-star one.
What a strong answer sounds like
A strong vendor gives you the founding year, names its owners, and states a retention rate with a number attached. It says something like "our average active client relationship runs about three years, and we can introduce you to two clients in year four." It produces the certification and the audit date without hedging. Retention is the most credible signal in this entire category, because high churn is almost impossible to hide once you ask for tenure data.
What a red flag answer sounds like
"We've been in business a long time and have many satisfied clients." No retention number. No client tenure. A certification that's "in progress" or expired. A reluctance to share the full Clutch reviews. And the tell that should make you sit up: heavy revenue concentration the vendor tries to reframe as "deep strategic partnerships." Sometimes that's true. Often it's fragility wearing a nicer word.
Security, IP, and legal
Intellectual property ownership in software outsourcing is determined by contract, not by who writes the code. Under a work-for-hire arrangement the client owns the resulting code outright, while a license arrangement leaves ownership with the vendor and grants the client usage rights. Source code escrow, jurisdiction for disputes, and the scope of the NDA are the contractual details that most often surprise buyers after signing.
This is the section most competitors skim. It's also where the expensive surprises live, so it gets the depth it deserves.
Questions to ask:
Who owns the IP for the code your developers write for us, and where is that stated in the contract?
Is the arrangement work-for-hire, or are you granting us a license to use the code?
What jurisdiction governs the contract, and where would a dispute be resolved?
What's the scope of your NDA, and what does it specifically not cover?
How do you handle data residency and GDPR or UK GDPR compliance?
What's your data breach notification process and timeline?
Who on your side has access to our codebase and production data, and how is that access logged?
What happens to our data and code if we terminate the contract?
Do you subcontract any of our work to third parties or freelancers, and if so, how does that affect IP ownership and security?
IP ownership: the question most companies forget to ask
Here's the trap. People assume that because they paid for the code, they own it. That's not automatically true. Ownership comes from the contract language, not from the invoice.
Under a true work-for-hire assignment, the IP transfers to you, fully, the moment it's created. Under a license, the vendor keeps ownership and grants you the right to use the software, sometimes with limits you won't notice until you try to take the code to a different vendor, or get acquired, and someone in due diligence asks who actually owns the codebase.
The question to ask is precise: "Does the contract assign all IP to us as work-for-hire, or do you retain ownership and license it to us?" A strong vendor answers in one sentence and points you to the clause. If the answer involves a lot of words about "industry standard practice" and no clause, get a lawyer to read the agreement before you sign anything.
One more piece people skip: jurisdiction. If your vendor is in one country and you're in another, decide upfront where a dispute would actually be resolved. A contract you can only enforce in a court 6,000 miles away, in a language you don't read, is weaker than it looks on paper.
What a strong answer sounds like
The vendor knows its own contract. It states the IP arrangement plainly, points to the specific clause, and explains the jurisdiction and what governs a dispute. It can describe its breach notification timeline in hours, not "promptly." It treats your termination and data-handover question as reasonable, because it is.
What a red flag answer sounds like
Anything that converts a contract question into a trust question. "You don't need to worry about that, we've never had an issue." Reluctance to put IP assignment in writing. No escrow option and no clear reason. A breach process that's improvised on the spot. If a vendor gets defensive about security and legal questions, that defensiveness is the answer. Remove them from your shortlist.
Team composition and talent stability
Outsourced development team stability is assessed through annual turnover rate, seniority balance, and average developer tenure on individual client accounts. Across the software industry, engineering roles see some of the highest turnover of any function, and attrition above roughly 20 percent a year is widely treated as a warning sign because of the knowledge loss it causes. The strongest vendors keep developers on the same client account for multiple years and can show it.
The people are the product. A vendor's logo doesn't write your code; specific developers do, and whether those developers stay is the single biggest driver of whether your project keeps its memory.
Questions to ask:
How often do developers change on projects, or can I expect to have one team working with me throughout the project?
How do you structure seniority on a team? What's the ratio of senior to mid to junior?
What's the average tenure of developers on a single client account?
If a developer leaves mid-project, what's your knowledge transfer process?
How long does it take a replacement developer to become productive on our codebase?
How do you handle vacation, sick leave, and coverage?
What's the English proficiency level of the developers we'd work with directly?
How do you manage time zone overlap with our team?
Will we interview the actual developers assigned to us, or a representative sample?
That last question catches a common bait-and-switch. Some vendors show you their best senior engineers in the sales process, then staff your project with whoever's available. Insist on interviewing the people who will actually be on your team, and get their continuity in writing.
How to read a vendor's turnover rate
Turnover numbers need context, or they'll mislead you in both directions.
Software engineering carries high turnover almost everywhere. It's consistently among the highest-churn roles in the labor market, so a vendor reporting low single-digit attrition is either exceptional or rounding creatively. What you're really probing isn't the company-wide number. It's account-level continuity: how long do developers stay on the same client.
The threshold worth remembering is that once annual turnover climbs past roughly 20 percent, knowledge loss starts to bite hard. Research on engineering teams has put the lost-knowledge cost of crossing that line at a meaningful share of project-specific context, the kind of context that doesn't live in documentation and walks out the door with the person.
So the strong move is to ask two questions and compare them. Company-wide turnover gives you the baseline. Average tenure on a single account tells you whether your team would actually hold together. A vendor with healthy company numbers but constant rotation on individual accounts is a vendor where you'll be re-explaining your architecture every quarter.
What a strong answer sounds like
A real number for turnover, stated without flinching, ideally with the account-level tenure number next to it: "Company-wide we're around 12 to 14 percent, and on long-term accounts our developers typically stay two-plus years." A concrete knowledge-transfer process: documented onboarding, paired handovers, a ramp-up window measured in weeks with a named approach. A clear yes to interviewing your actual team.
What a red flag answer sounds like
"We don't really track that." A refusal to commit to team continuity in writing. A knowledge-transfer process that amounts to "the new developer reads the code." Or a suspiciously perfect turnover number with nothing behind it. Vague answers here are the most expensive kind, because the cost arrives months later, disguised as "the new developer is still getting up to speed."
Delivery process and project management
Software development outsourcing delivery processes should include a named methodology backed by specific artifacts: sprint cadence, sprint demos, retrospectives, a defined status reporting format, and a documented process for handling scope changes. A vendor that names a methodology but cannot describe its concrete artifacts is describing an aspiration, not a practice.
Naming a methodology is easy. Everyone says "Agile." The questions that matter probe whether the practice is real.
Questions to ask:
What's your delivery methodology, and what does a typical sprint look like for you?
How long are your sprints, and what specifically happens in a sprint demo?
Do you run retrospectives, and can you give an example of something one changed?
What does your weekly status report contain, and can we see a sample?
What's your escalation path when something goes wrong, and how fast does it move?
How do you handle a scope change request mid-sprint?
How is QA integrated? Is it a separate phase or built into the sprint?
What's your approach to CI/CD, and what's automated versus manual?
What project management and communication tools do you use, and will we have direct access?
How do you measure and report on velocity and delivery predictability?
The one process question that reveals the most
If you only get to ask one process question, ask this: "Walk me through what happens when a sprint is going to miss its commitment. Who finds out, when, and what do you do?"
The answer exposes everything. A mature vendor has a real answer because it has lived through missed sprints, every team has, and built a process around catching them early. It'll describe how the problem surfaces in standup or burndown, who escalates it, when you'd hear about it, and what the options are. That's a team that tells you bad news while it's still cheap to fix.
A weak vendor gets vaguely optimistic here. "We work hard to make sure that doesn't happen." That answer means you'll find out a sprint is blown when it's already blown, in a status report that was green right up until it wasn't.
Watch for one specific inaccuracy, too. If a vendor describes a two-week sprint with "weekly demos," those aren't weekly demos, that's one demo per sprint. The slip is small but it tells you whether they're describing their actual practice or reciting a methodology they read about.
What a strong answer sounds like
Specific artifacts, not just method names. A real sprint cadence, an actual sample status report, a named escalation path with a timeline. A retrospective example with a concrete change that came out of it. A scope-change process that's defined before you need it. Direct access to the project management tools, so you're seeing the work, not a curated summary of it.
What a red flag answer sounds like
Methodology buzzwords with no artifacts behind them. No sample status report. QA described as something that happens "at the end." An escalation path that's really just "email the account manager." And the optimistic dodge on the missed-sprint question, which is the single most reliable tell that a vendor's process is theater.
Scaling, pricing, and commercial terms
Software outsourcing engagement models fall into three main categories. Time-and-material bills for actual hours worked and suits evolving scope. A dedicated team provides a fixed group of developers at a recurring cost and suits long-term product work. Fixed-price sets a defined cost for a defined scope and suits well-specified, stable projects. The right model depends on how clearly the work can be specified in advance.
Pricing isn't just the rate. It's the model, and the model determines who carries the risk when reality diverges from the plan, which it always does.
Questions to ask:
Which engagement models do you offer: time-and-material, dedicated team, developers on retainer, or other options?
For our kind of project, which model do you recommend, and why?
How do you handle scaling the team up or down, and what notice do you need?
What are your rates by seniority level, and what's included versus billed separately?
How do you bill: what's your invoicing cycle and payment terms?
What service-level commitments do you make, and what happens if you miss them?
Is there a minimum commitment or ramp-down penalty?
What happens at the end of the engagement: how does offboarding, code handover, and documentation work?
Who owns the documentation, and is it kept current or written at the end?
Know the three models before the call so you're not learning vocabulary while you're trying to evaluate.
Time-and-material bills for hours actually worked. It fits projects where scope will evolve, which is most projects honestly, and it puts flexibility on your side and discipline on theirs. A dedicated team gives you a fixed group of developers at a recurring monthly cost; it fits ongoing product development where you want continuity and direct control over priorities. Fixed-price sets a cost for a defined scope; it fits only genuinely well-specified, stable work, because every change becomes a renegotiation. If a vendor pushes fixed-price for an exploratory project, they're either inexperienced or pricing in a fat risk buffer you'll pay for.
The end-of-engagement questions are the ones people skip and regret. Offboarding is where outsourcing relationships go quietly wrong. Ask how code is handed over, whether documentation is maintained throughout or scrambled together at the end, and what the vendor's obligations are after the final invoice. A vendor that has thought about how you leave is a vendor that's confident you'll want to stay.
What a strong answer sounds like
A clear explanation of each model and an honest recommendation that sometimes argues against the most expensive option. Transparent rates by seniority. A real offboarding process with documentation maintained as you go. Service-level commitments with actual consequences attached. A recommendation that fits your project, not their margin.
What a red flag answer sounds like
One model offered as the only option. Rates that are hard to pin down or padded with vague "management fees." No offboarding plan, or documentation treated as an afterthought. Pressure toward fixed-price for work that clearly isn't fixed. And any service-level "commitment" with no consequence behind it, which is just a sentence, not a commitment.
The AI-era questions your vendor can't dodge
Evaluating a software vendor's use of AI coding tools requires asking whether developers use AI assistants, whether the vendor has a written AI-use policy, and how AI-generated code is reviewed for security and IP risk. AI-assisted code has been shown to churn at a higher rate than human-written code, so review rigor matters more, not less, when AI is in the workflow. This category is largely absent from competing vendor evaluation guides.
This is the section nobody else is asking about yet, which is exactly why it separates the vendors who are thinking from the ones who are coasting.
AI coding assistants are in most professional development workflows now. That's not a problem on its own. Used well, they speed up real work. Used carelessly, they introduce code nobody fully understands, with security and IP questions attached. You want a vendor that has a position on this, in writing.
Questions to ask:
Do your developers use AI coding assistants like GitHub Copilot or Cursor? Which ones?
Do you have a written AI-use policy?
How do you review AI-generated code differently from human-written code, if at all?
How do you handle the IP and licensing questions around AI-generated code?
What's your policy on putting our proprietary code into AI tools?
How do you keep AI-assisted code from introducing security vulnerabilities?
Can you measure how much of the delivered code is AI-assisted, and do you track its defect or rework rate?
Question 50 is the one to watch closely. If a developer pastes your proprietary code into a consumer AI tool to get help, where does that code go, and who can see it? A vendor with a real policy has already answered this for itself. A vendor without one is improvising with your IP.
And there's a quality dimension people miss. AI-assisted code tends to get rewritten and thrown away at a higher rate than code a human wrote deliberately, which means review can't get lighter when AI is in the loop, it has to get more rigorous. A vendor that has noticed this, and adjusted its review process, is a vendor paying attention. One that treats AI as a free speed boost with no downside hasn't been burned yet, and you don't want to be the project where they learn.
What a strong answer sounds like
A clear yes on which tools are used and a written policy to back it up. A review process that treats AI-generated code with at least as much scrutiny as human code, sometimes more. A firm rule against putting client code into tools that would train on it or expose it. An honest acknowledgment that AI changes the review burden rather than removing it.
What a red flag answer sounds like
"We don't use AI" (rarely true, and if true, ask why they're a generation behind). Or the opposite: enthusiastic AI use with no policy, no differentiated review, and no awareness of the IP exposure. Both extremes are a problem. The dangerous one is the vendor treating AI as pure upside, because that's the one shipping code nobody on the team can fully explain.
Staff augmentation versus project outsourcing: different questions
There's a fork most guides ignore, and it changes which questions matter.
Staff augmentation means the vendor provides individual developers who plug into your existing team, under your management and process. You own the delivery process; you're buying capacity and skills. Project outsourcing means you hand over a defined piece of work and the vendor owns the delivery, including project management, process, and the outcome.
If you're augmenting your team, the delivery-process questions matter less, because the process is yours. What matters more is individual developer quality, English proficiency, time zone overlap, how fast someone integrates into your existing workflow, and how easily you can swap a developer who isn't the right fit. You're hiring people, effectively, so vet them like people.
If you're outsourcing a project, the process questions become central, because the vendor's delivery machine is what you're actually buying. Methodology, escalation paths, status reporting, and QA integration carry far more weight, because you're trusting the vendor to run the work, not just supply the hands.
Asking the wrong set for your model is a common and quiet mistake. Grill a staff-augmentation vendor on its sprint retrospective format and you'll learn very little that matters, because you'll be running the sprints. Skip the process questions with a project-outsourcing vendor and you've left the most important thing unexamined.
Quick-reference checklist
| Category | Questions | Lead with on first call? |
|---|---|---|
| Company stability and credibility | Founding year and ownership; employee count and engineer ratio; retention rate and average client tenure; long-term client references; ISO 27001 and SOC 2 Type II and audit dates; Clutch rating and full reviews; recent layoffs; revenue concentration | Yes |
| Security, IP, and legal | IP ownership and contract clause; work-for-hire versus license; jurisdiction for disputes; source code escrow; NDA scope; GDPR and UK GDPR and data residency; breach notification timeline; access controls and logging; data and code on termination | Yes (the disqualifiers) |
| Team and talent stability | Annual turnover rate; seniority ratio; average tenure per account; knowledge transfer process; replacement ramp-up time; leave coverage; English proficiency; time zone overlap; interviewing the actual team | Deep-dive |
| Delivery process | Methodology and sprint shape; sprint length and demo content; retrospectives with examples; status report contents and sample; escalation path and speed; mid-sprint scope changes; QA integration; CI/CD automation; tools and access; velocity and predictability | Deep-dive |
| Scaling, pricing, commercial | Engagement models offered; recommended model and why; scaling up and down; rates by seniority; invoicing and terms; service-level commitments and consequences; minimum commitment or ramp-down penalty; offboarding and code handover; documentation ownership and currency | Deep-dive |
| AI practices | AI assistants used and which; written AI-use policy; differentiated review of AI code; AI code IP and licensing; policy on proprietary code in AI tools; AI security review; measurement of AI-assisted code and its rework rate | Deep-dive |
How Brights approaches vendor questions
We field these questions on discovery calls regularly, and the honest truth is the deep ones are our favorite kind, because the answers are where a real partner separates from a capacity-for-hire shop.
A few specifics, since the rest of this guide has been about demanding specifics. We can produce client retention figures and name long-term accounts rather than gesturing at "many satisfied clients." Our engagement models, time-and-material, dedicated team, and project-based, come with an honest recommendation about which fits your work, including the times that recommendation is the less expensive one. And we have a position on AI in the development workflow, in writing, because "AI-enhanced delivery" should mean a reviewed, accountable process, not a speed boost with the brakes off.
The point isn't that we'll answer every question the way you hoped. It's that we'll answer them with numbers and clauses you can check, which, after reading this far, you'll recognize as the whole game.
Want to run a structured discovery call? Talk to our team and bring the hard questions. We'd rather earn the engagement on the deep ones.
FAQ.
Fewer than you think on the first call, more than you think overall. On an initial screening call with several vendors, lead with eight to ten questions covering company stability and the security and IP issues that would disqualify a vendor outright. Save the full set, 60-plus across all six categories, for a deep-dive session with the two or three vendors who pass the screen. Asking everything of everyone exhausts the room and teaches you less than asking the right things at the right depth.