How to Evaluate a Software Outsourcing Company Before Signing

By the time you are choosing between two or three outsourcing companies, most of them will look credible on paper. The difference between a good and a painful engagement usually lies in details that proposals do not volunteer: who actually works on your project, which assumptions sit behind the estimate and what happens when things change. This guide gives you a sequence of checks and a scorecard you can use with any vendor.

Assess the work you actually need

Write a short requirement before evaluating anyone. It should state the business goal, the users, the core journeys for the first release, required integrations, constraints such as security reviews or data residency, and your preferred engagement model. Mark which requirements are non-negotiable and which are nice to have.

A clear requirement does two things. It lets vendors respond to the same problem, so proposals become comparable. And it reveals vendors who ask good questions: a partner that challenges an assumption or spots a missing integration early is showing the behaviour you want during delivery.

Verify relevant delivery evidence

Public claims are a starting point, not proof. For each vendor, look for evidence that matches your project:

• Case studies with attribution: a named product or client, the vendor’s actual role and the platforms involved. Be careful with screenshots or logos that do not state what the vendor built.
• Directory reviews: read the full text of reviews from projects similar to yours, note the date and project size, and treat ratings as context rather than a score.
• References: ask for two clients with comparable scope and call them. Ask what went wrong and how the vendor responded.
• Technical artefacts: where confidentiality allows, review a sample architecture document, test plan or code excerpt.

Separate evidence for the company from evidence for the proposed team. A company may have delivered excellent mobile apps with a team that is not available to you.

Evaluate the proposed team

Ask each vendor to name the people who would work on your project, with role, seniority, location and allocation. Then:

• Interview the tech lead and at least one developer.
• Ask how decisions are made when requirements are unclear.
• Ask how code review, testing and releases work day to day.
• Confirm who is accountable for delivery and who you escalate to.
• Ask what happens if a team member leaves during the project.

Review estimates and assumptions

Never compare totals first. Line up the proposals and compare:

• Scope covered: features, platforms, integrations, admin tools.
• Assumptions: content provided by you, third-party APIs available, design approved by a certain date.
• Exclusions: hosting, licences, store fees, data migration, post-launch support.
• Included services: project management, QA, DevOps, design.
• Commercial model: fixed price, time and materials or dedicated team.
• Change process: how new requests are estimated and approved.

A low estimate that excludes QA and assumes perfect requirements is not cheaper than a higher one that includes them. Ask vendors to fill gaps until the proposals describe the same work.

Discuss ownership, security and handover

These topics belong in the contract, so involve your legal adviser; this guide does not replace legal advice. Before signing, make sure you understand:

• Who owns the code and when ownership transfers.
• Where repositories, cloud accounts and app store accounts live. Ideally in your organisation, with vendor access.
• How confidential information and personal data are handled.
• What security practices apply: access control, device security, secrets management.
• What a handover includes: documentation, credentials, knowledge transfer and access removal.

Run a structured selection

Score each vendor with the same weighted scorecard. The weights below are an illustrative starting point; adjust them to your priorities.

Score independently with two or three colleagues, then discuss differences. If the top two vendors are close or the project is high-risk, consider a short paid pilot or discovery phase with clear acceptance criteria. A few weeks of real collaboration tells you more than any proposal.

Common evaluation mistakes

• Choosing on price alone. The cheapest proposal often omits work that reappears as change requests.
• Meeting only sales staff. The people you meet before signing should include the people who will deliver.
• Ignoring the change process. Every project changes; the question is how efficiently.
• Accepting vague ownership terms. Fixing account and IP ownership later is much harder.
• Skipping references. A 20-minute call with a past client is one of the cheapest checks available.

Frequently asked questions

How many vendors should I evaluate?

Three is usually enough to compare approaches without overwhelming your team. Start wider, then shortlist using a quick screen of evidence and fit.

Should I ask for a free proof of concept?

Free work rarely reflects real delivery. A small paid pilot with acceptance criteria gives better evidence and treats both sides fairly.

How important are certifications?

They can be relevant for regulated work, but verify them with the issuer and still evaluate the actual team and process.

What if vendors refuse to name team members?

Some vendors confirm names only after signing. Ask at least for role profiles and the right to interview key people before the project starts.