How can we tell whether a software outsourcing company is reliable?
Do not judge a software supplier by slogans about a large portfolio or strong technology. Verify how it understands your work, who will actually serve the project, what its delivery artefacts look like, where the contract boundaries sit, how progress can be inspected, and whether another team could take over.
A high price is not proof of reliability, and a large company is not automatically the right fit. Match due diligence to risk: a brochure site needs a lighter review than a system handling customer data, payments, production control, or core operations. Screenshots, awards, and sales assurances are leads, not evidence.
When turning a business goal into an executable scope, also compare Should a small project hire a specialist team or a large software company? and Who operates the system after launch if we have no technical staff?; the linked guidance adds context that should be considered in the same decision.
| Check | Evidence to request | Warning sign |
|---|---|---|
| Understanding | Retelling of your workflow, exceptions, and exclusions using your cases | A page-based total quote and “yes” to every request |
| Assigned team | Named roles, availability, and participation by delivery leads | Senior sales team, unspecified contract resources |
| Delivery quality | Redacted requirements, test, deployment, and handover samples | Only final-interface screenshots |
| Commercial scope | Itemized scope, assumptions, dependencies, third-party cost, and change rules | Low quote omitting migration, testing, or operations |
| Security and continuity | Access, backup, vulnerability, staffing, and incident procedures | Accounts, keys, and data controlled by one individual |
| Exit and takeover | Repository, data export, accounts, documentation, and assistance period | Only a binary package or restricted client access |
Normalize competing quotations to the same work list: discovery, design, frontend and backend, administration, integrations, migration, testing, deployment, training, warranty, operations, cloud resources, and third parties. The evaluator should derive appropriate platform, load, data, security, and acceptance assumptions; the client should not have to invent a technical architecture before comparison. A justified contingency is not automatically padding, just as a missing workstream is not genuine savings.
Ask each finalist to explain or prove one high-risk area: migrate a small redacted dataset, connect to a real API sandbox, demonstrate restore, or have a takeover developer explain an unfamiliar module. Define ownership and payment for any proof; do not solicit extensive unpaid design to hand to another bidder. Contact references independently and ask about delay, changes, incidents, and handover—not simply whether they were satisfied.
The SOW should cover deliverables, exclusions, dependencies, milestones, acceptance samples and timing, defect severity, change pricing, delay, third-party cost, intellectual property, privacy, confidentiality, incident notification, termination, and exit support. Source-code ownership alone is insufficient if domain, cloud, app-store, certificate, monitoring, backup, and supplier accounts remain outside the client's control. A qualified lawyer should confirm legal effect under the applicable law.
CISA's Software Acquisition Guide fact sheet supports structured questions about software assurance and supply-chain practice. Like any checklist, it helps expose risk; it cannot certify that a supplier is absolutely reliable.