Outsourcing software development or IT operations can add capacity or specialist skills, but it also introduces delivery, security, continuity and knowledge-transfer dependencies. A structured supplier review makes those dependencies visible before a contract is signed.
The seven questions below form a practical evaluation framework. For each, the guide describes useful evidence and signals that deserve follow-up. Adapt the depth of due diligence to the access, data and business consequence involved; NIST's supplier due-diligence guidance provides a broader framework for ICT supply-chain assessment.
1. Do they ask about your business, or only your backlog?
A good partner wants to understand why you're building something before discussing how. If the first conversation jumps straight to rates and headcount, expect a body shop, not a partner.
Useful evidence: they ask who the users are, how success will be evaluated, and what happens to the business if the work is late. They can explain assumptions and trade-offs instead of agreeing to every request without analysis.
Warning signs: a quote arrives before anyone has asked what the software is for; every answer is "yes, we can do that"; the people in the sales call can't explain your business back to you.
2. Who exactly will work on your project?
Ask to meet the people expected to lead or perform the work, not only the sales contact. Confirm which named roles are committed, which may change and how any substitution will be communicated.
Clarify before signing:
- Are they employees or subcontractors? Subcontracting isn't automatically bad, but you should know who actually holds the knowledge — and who it walks away with.
- What is the team's seniority mix? A team of juniors with a distant "supervising architect" is a common cost-cutting pattern that shows up later as rework.
- What happens if a key person leaves? Ask for specifics: handover periods, documentation habits, how fast a replacement joins.
- Will the team be dedicated or shared across clients, and how will competing commitments be managed?
Good signs: you interview the actual lead engineer before signing, and the answers about turnover are concrete rather than reassuring.
3. How do they handle security?
A supplier may receive source code, credentials, environments or customer data depending on the scope. Its controls and incident handling therefore become part of your risk boundary and should be assessed in proportion to that access.
At minimum, expect:
- Access control with least privilege, and offboarding that removes a departing engineer's access the same day
- Encrypted secrets management (no passwords in chat!)
- A named person responsible for security incidents, and a straight answer to "when would you tell us about a breach?"
- Separation between your environment and their other clients'
Warning signs: credentials arrive through an unapproved channel during the sales process; "we've never had an incident" is offered instead of control evidence; or nobody can name who owns security and notification decisions.
4. What does "done" mean to them?
Agree on a definition of done before the first sprint: code reviewed, tested, documented, deployed, monitored. Teams that resist writing this down usually plan to skip parts of it.
A written definition makes acceptance more inspectable: a delivered feature can be checked against agreed evidence instead of relying on different assumptions about the word “done.”
Good signs: they have a written definition of done before you ask, and it includes tests and documentation. Warning signs: "we adapt to your process" with nothing written behind it, or testing quoted as a separate, optional line item.
5. Can they show you working software early?
Working evidence is usually more informative than percentage-complete reporting. Agree when the first reviewable increment should be available based on discovery needs, system access and delivery risk.
Define a review rhythm in the agreement and request access to an appropriate environment. The cadence can be weekly, fortnightly or milestone-based, but it should produce something stakeholders can inspect and respond to.
An early end-to-end increment also exercises environments, pipelines and deployment responsibilities while there is still time to address gaps in the delivery system.
6. How transparent is their pricing?
Fixed-price, time-and-materials and capped models allocate uncertainty differently. Ask how assumptions, change requests, reporting, unused budget and overruns work in the proposed model, then choose the structure that matches how well the scope is understood.
Whatever the model, you should always know what was done, by whom, and for how long. Ask what happens when they disagree with your priorities or think a request is a mistake — a partner who never pushes back on scope is billing you, not advising you.
Compare total expected cost, including internal coordination, environments, transition, rework and ongoing operation, rather than comparing hourly rates alone.
7. What happens at the end?
The exit is part of the deal. The time to negotiate it is when everyone is still friendly — at the start.
Ask the agreement to define:
- Ownership and licence terms for code, infrastructure definitions and documentation, plus which accounts the client controls during delivery
- A structured handover period with knowledge-transfer sessions, not just a repository export
- No lock-in through proprietary tooling or licenses that only the vendor holds
- Continuity terms: what notice period applies, and what support is available while you transition
Warning sign: any hesitation about who owns what. That conversation only gets harder later.
Common selection mistakes
- Choosing on rate alone. Hourly rate does not capture coordination, rework, transition or operating cost.
- Skipping practical validation. Where appropriate, a small paid pilot with the proposed team can test a real deliverable, access model and review process before a larger commitment.
- Not checking references. Ask specifically for a client whose project had problems — how a partner handles a rough patch is the real reference.
- Signing without an exit clause. You're not planning to leave; you're pricing the option to.
The bottom line
Price matters, but it is one part of the decision. Look for clear communication, inspectable delivery, proportionate security, explicit ownership and an exit path that can actually be exercised.