16 Questions to Ask When Outsourcing Software Development

Three vendors send proposals for the same project. Their portfolios look alike. Their prices do not. Each promises experienced developers, smooth communication and reliable delivery.

But how do you know which one can actually deliver?

This is where the right questions to ask when outsourcing software development make a difference. Even experienced technical leaders can struggle to compare competing proposals. What matters is whether a vendor can back up its promises with evidence.

How to Use These Questions at Each Stage of Selection

Do not ask all 16 questions on the first call. Start by confirming whether the vendor works within your budget range. Then discuss the most important questions at a high level and confirm what evidence the vendor can share if shortlisted.

Request the documents themselves after you shortlist two or three vendors.

These are starting points, not a fixed interview script. Adjust the questions to your project and save detailed evidence checks for shortlisted vendors.

The wider software development company selection process also helps you narrow your options before detailed evaluation.

What to Prepare Before You Contact Vendors

Define the problem, the scope and your limits first. If your requirements are unclear, vendors may make different assumptions, and their proposals will not be comparable.

Start with why you are outsourcing and how you will know it worked. Then list what you will hand over, such as existing code, databases and documents. Four more items make vendor answers easier to judge:

• A full feature list and a shorter list of what a first release truly needs.

• A budget range and a target date, with a fallback if either moves.

• One internal owner who can review progress every week, even if the vendor does the building.

• A technical reviewer who can join calls and read what vendors send. This can be an employee, an advisor or an independent consultant.

A clear software development scope of work helps document these requirements before vendor discussions begin.

Questions About Project Understanding and the Delivery Team

Start by understanding how the vendor approaches your project and who will actually deliver it. These questions help you evaluate its experience, team structure and ability to maintain continuity.

1. How will you learn our requirements before you start building?

Building from a few phone calls is risky, especially when you replace an existing system. Ask how the vendor discovers requirements, who it will interview on your side and which sources it will use, such as your current code, database, documents and users. Request a sample discovery document or requirements list from a past project.

2. Have you delivered something similar, and what went wrong?

Relevant experience can reduce avoidable surprises, though it guarantees nothing. Case studies usually show only the wins, while a difficult project reveals how the vendor responds when plans change.

Ask for two examples close to your size, industry and technology, plus one project that hit problems and what changed afterward. Request a reference call for at least one of them. Watch for vendors who say nothing has ever gone wrong, or whose examples match your industry but not your scale or technology.

3. Who will do the work and who is accountable for delivery?

The people in the sales meeting are not always the people who build the product. Ask who will lead the project, which roles are confirmed and when the remaining team members will be assigned. Meet the proposed technical lead before signing and clarify how staffing changes will be approved. Ask who is accountable for technical delivery and who resolves blockers. Ask whether any work goes to subcontractors or freelancers, since that affects both quality and who can see your data.

Some project-based vendors cannot name every developer before signing, so that alone is not a warning sign. Be cautious about vague answers such as "a senior team" with no named lead or no approval process for changes.

4. What happens if a key engineer leaves?

Turnover is normal. The real question is how much knowledge leaves with each person. Ask how replacements are chosen and how long a new engineer typically needs to become productive on a system like yours. Request examples of what gets documented on a typical project, such as architecture decisions and setup guides.

A strong answer describes a process, such as overlapping handovers and written documentation. Be cautious if the answer is "the new developer will read the code."

Questions About Process, Quality and Communication

A capable team still needs a reliable way to deliver. Ask how the vendor tracks progress, verifies quality and keeps decisions moving throughout the project.

5. How will you show us that the project is making progress?

Saying "we are Agile" costs nothing. A working backlog, a demo and a status report take real effort, which is why they tell you more. What you review depends on the delivery approach. It might be a demo at the end of each sprint (a short development cycle, often one to four weeks), a completed milestone or working software released continuously.

Ask how the team tracks planned work, completed tasks and upcoming priorities. Depending on the delivery approach, this might be a shared backlog, a milestone plan or a project dashboard.

Agree on who sets priorities, who approves changes and how the vendor estimates the work. Your business should retain control over the outcomes it needs, even when the vendor manages delivery.

Request access to the relevant project tracking system, a sample demo or milestone report and a sample status report from a past project. Watch for status reports with no working software behind them. Tracking how many important features are complete and tested can help you judge whether the project is progressing as planned.

6. How will quality be tested and accepted?

Agree on what "done" means before development starts. These are the acceptance criteria, the conditions the software must meet before you approve it. Ask how testing is built into each development cycle, whether automated tests are part of the work and what must pass before you accept a feature. Request a sample test plan and acceptance criteria from a past project. Ask who pays for defects found after acceptance and for how long.

A test coverage percentage does not prove quality, and a very high number can mean tests were written to hit the figure. Ask which quality measures the vendor tracks and how the team uses them. Watch for testing that happens only at the end. Independent code quality assessment can provide another perspective on the software being delivered.

7. How quickly can we reach the team, and who is our main contact?

Imagine a developer who needs an urgent decision, but your teams share no working hours. The answer waits overnight, and the same delay repeats all project long. Ask how many working hours overlap with yours, who your single point of contact is and how issues are escalated. Request the communication plan, including meeting rhythm and tools.

Watch for communication limited to scheduled reports. If your teams work in different time zones, agree on overlapping hours for important discussions. Also define response times and a clear process for urgent decisions.

Questions About Pricing and Hidden Costs

Two proposals can look similar but cover very different work. These questions help you understand what you're paying for, what's excluded and how costs could change.

8. Which pricing arrangement do you recommend and why?

Fixed-price contracts can work when requirements are clear and unlikely to change. Time and materials means paying for the work actually performed. It can suit projects where requirements evolve, but costs still need regular review.

A dedicated team is a staffing arrangement, not a pricing model. It can support ongoing product development and may use monthly fees or time-based billing.

On the first call, share your budget range and ask whether the vendor works at that level. At the shortlist stage, ask which arrangement fits your project, how costs will be tracked and what happens when priorities change. Request a sample estimate with ranges and assumptions. Also ask why one bid is far lower or higher than the others, since either can signal missing scope. Software development cost benchmarks give a starting point for comparing quotes.

9. What is not included in your estimate, and how do you handle changes?

Imagine a proposal that quotes only development hours. Testing, deployment and support would then land on your budget later. Ask whether each of those is included, along with project management, third-party licenses and extra work. Request a written list of assumptions and exclusions, the rate card for extra work and any minimum commitment or notice period for reducing the team.

Questions About Security, Compliance and AI Use

Your vendor may need access to sensitive data, source code and internal systems. Before granting that access, establish which safeguards, legal obligations and AI-use policies apply.

10. How do you protect our data, and can you show proof?

Security claims need documents behind them, but the right level of proof depends on your project, the sensitivity of your data and the risk. A vendor without ISO 27001 or SOC 2 is not automatically unsuitable.

ISO/IEC 27001 is an international standard for information security management systems. A SOC 2 report comes from a licensed CPA firm and describes a vendor's controls. A Type 1 SOC 2 report usually assesses control design at a point in time, while Type 2 assesses how controls operated over a period.

If a vendor cites either one, ask three things: What does the evidence cover? Is it current? Does it apply to the services you are buying?

On the first call, ask what security evidence the vendor holds and whether it will share it under a confidentiality agreement. At the shortlist stage, ask for the document itself, not a logo, and check its scope, dates and issuer.

No certificate proves complete security. One certification body notes that ISO 27001 certification does not mean data can never be lost. Also ask who can access your code and data and how fast the vendor must report a breach. Relevant cybersecurity best practices can help you evaluate these safeguards.

11. Which regulations apply to our data and who is responsible for what?

Outsourcing the work does not outsource your legal responsibility. Ask which rules the vendor believes apply and what it will sign.

When GDPR applies and a vendor processes personal data on your behalf, Article 28 generally requires a written agreement covering that processing. The agreement must address matters such as subprocessors, meaning other companies that process personal data for the vendor, and what happens to personal data when services end.

For protected health information in the United States, HHS guidance says the business associate contract must set permitted uses, require safeguards and breach reporting and address return or destruction of data at termination.

Request the vendor's standard data processing terms and its list of subprocessors. Watch for "we are compliant" with no named contract or controls. Rules vary by country and industry, so have a lawyer review anything that touches regulated data.

12. How do you use AI tools on our code?

AI coding assistants are common, so the useful question is how the vendor controls them. Ask which tools developers use, whether a written policy exists and whether your code can be sent to outside AI services. Ask how AI-generated code is reviewed, tested and scanned, and who is accountable for defects. Request the policy and a sample review checklist.

NIST's Secure Software Development Framework gives buyers a common vocabulary for discussing secure development with suppliers. AI-generated code deserves at least the same review and testing as any other code.

Watch for answers about speed only. A blanket "we do not use AI" is hard to verify and deserves a follow-up. The same concerns are explored in AI-generated code quality.

Questions About Ownership, Support and Exit

The relationship doesn't end when the software launches. These questions establish what you'll own, what support you'll receive and how easily you can move to another provider if needed.

13. Who will own the code and other deliverables?

Paying for code does not automatically mean you own it. Ownership depends on the contract. Ask whether all code, designs and documentation will be assigned to you and in which clause. Request a draft of the intellectual property section early.

Start with who owns the work when it is created and what must be transferred to you. In the United States, the Copyright Office explains that work employees create within the scope of their jobs belongs to their employer. For commissioned work, U.S. work-made-for-hire rules apply only in certain circumstances. Software is not a separate category under those rules.

The agreement should clearly define which rights transfer to you and which components remain licensed. Rules differ by country, so ask counsel to confirm the approach for your jurisdictions.

Watch for "industry standard" answers with no clause behind them. Also watch for arrangements where the vendor keeps ownership and licenses the code back to you.

14. Are we buying custom software or customizing your platform?

Custom software is written for you and can often be maintained by another team. A customized vendor platform may depend on the vendor's framework, license and developers for as long as you use it.

Custom code can also rely on proprietary components, so dependence is a question of degree. Ask which one the proposal describes, who owns the underlying framework and what license terms apply after the project ends. Request the license agreement and a list of third-party components.

Imagine a vendor that proposes to rebuild your application on its own framework. The price may look fair, yet you might be unable to move the system to another team later. Watch for answers that avoid license terms, and ask what it would cost to move the system elsewhere.

If you are replacing or modernizing an existing system, ask one more question. Does the vendor propose a full rewrite, and why? Software entrepreneur Joel Spolsky argued in a widely cited 2000 essay that rewriting from scratch is among the costliest mistakes a software company can make.

That is an influential expert view, not proof that every rewrite fails. Ask for a business case that compares a rewrite, gradual refactoring (improving existing code without changing its intended behavior) and leaving the system as is. Be cautious if the rewrite exists mainly because the vendor prefers its own framework.

15. What support and warranty do you provide after launch?

Launch is not the end of the work. Software needs fixes, security updates and changes, and someone must be responsible for them. Ask what the vendor covers after launch, how long it fixes defects at no extra charge, how quickly it responds to urgent issues and what ongoing maintenance costs. Request the support terms in writing, including response times and how the contract separates a defect from a new feature. Software maintenance costs should be part of your longer-term budget.

Watch for "we will support you" with no terms. Also ask who will provide support if the original team has moved on.

16. What does a handover look like if we leave?

Receiving source code is not the same as receiving a usable handover. A usable handover includes build and deployment instructions, architecture documentation, access to repositories and cloud accounts and time for knowledge transfer. Ask what the vendor delivers at the end, who controls the repository during the project and what happens to your data. Request a written handover checklist. Where the engagement allows it, ask for buyer-controlled access to the repository and cloud accounts, plus transferable documentation, from the start.

Documentation promised only for the end can be rushed, so ask for it to be kept current throughout. If personal data is involved, the contract should also say how it is returned or deleted.

How to Verify What Vendors Tell You

Check every important answer against a document, a demonstration or an independent voice. Ask every shortlisted vendor for the same items. Comparable evidence makes differences visible and keeps the process fair.

Reference calls can reveal how a vendor performs after the contract is signed. Ask former clients what went well, what caused problems and how the vendor responded. Vendors usually choose their own references, so compare these accounts with independent reviews and other available evidence. If a reference has nothing negative to say, ask again more specifically.

Review platforms and directories can help you build a shortlist. Look beyond ratings to understand the project's scope, the client's actual experience and how the vendor handled problems.

Give vendors a clear goal and see whether they ask about your business. For larger projects, consider a small paid pilot before a long contract, since a trial shows how a team works under real conditions.

How to Compare Vendor Responses

Assess every vendor on the same evidence. A scorecard supports your judgment. It does not replace it.

For each area, record two separate things:

• Evidence status: missing, unverified or verified. Verified means the evidence is relevant, current and confirmed by you, a reference or an independent reviewer.

• Evaluation outcome: acceptable, needs clarification or unacceptable. This judges what the evidence shows. A verified reference call that confirms repeated missed deadlines is verified evidence with an unacceptable outcome.

Some decisions need expert input. Send ownership, licensing, data protection and termination clauses to a lawyer. Ask a technical reviewer to read security documents, architecture proposals and any rewrite plan.

Making the Final Decision

Choosing a software development partner is not about getting perfect answers to every question. It is about finding out how the vendor actually works and whether the evidence supports its promises.

Focus on the risks that matter most to your project. Compare shortlisted vendors using the same criteria. Check their experience, delivery process, commercial terms and plans for handling problems. Before signing, have the important technical and contractual details reviewed.

The right partner is not necessarily the one with the lowest quote or the strongest sales presentation. It is the one whose capabilities, responsibilities and working arrangements fit what your business needs.