How to evaluate an IT outsourcing provider before you sign

Choosing an IT outsourcing provider based on its rates, its references or the résumés it presents isn’t enough.

The future quality of the collaboration depends above all on how it is really organized: code review, testing, CI/CD, steering, team stability, security and knowledge transfer.

These elements are often mentioned in sales presentations. But before signing, the challenge is to verify that they are actually applied.

Here are the criteria to analyze, the evidence to ask for and the warning signs to watch out for.

Why quality is the real issue in IT outsourcing

When an outsourced project runs into trouble, it is rarely the fault of a single developer. The problem often comes from a delivery system that lacks safeguards.

Quality deteriorates when:

• requirements are vague or change without arbitration;
• code isn’t systematically reviewed;
• testing comes too late in the project;
• environments are unstable;
• production releases rely on manual actions;
• knowledge is concentrated in one or two people;
• steering isn’t based on any reliable indicator.

Conversely, quality stabilizes when:

• responsibilities are clearly assigned;
• a Definition of Done governs every delivery;
• code reviews and tests are systematic;
• deployments are automated and controlled;
• decisions, risks and documentation are shared;
• quality is measured, not just felt.

The country where the team is located therefore doesn’t guarantee quality. Madagascar, and Mauritius can both be relevant destinations, but the outcome depends above all on the provider’s engineering practices, technical leadership and governance.

The 7 criteria for choosing an IT outsourcing provider

1. Quality standards that are actually applied

A provider can easily claim that it places great importance on quality. But that promise is worthless without concrete processes.

Before committing, check:

• the development conventions used;
• the code review rules;
• the different levels of testing planned;
• the criteria for considering a feature done;
• how responsibilities are split between developers, the tech lead, QA and the Product Owner.

Evidence to ask for:

• an anonymized example of a Definition of Done;
• a checklist used during code reviews;
• an example of a test report;
• the rules applied before a pull request is merged.

Question to ask:

What technically prevents code that hasn’t been reviewed or tested from going to production?

Warning sign:

Quality depends solely on a manual check carried out at the end of the sprint or before the production release.

2. A CI/CD pipeline capable of securing deliveries

Without continuous integration and deployment, deliveries depend more on manual interventions and are therefore more prone to errors.

A structured CI/CD setup can include:

• checking code formatting and quality;
• running tests automatically;
• analyzing dependencies and vulnerabilities;
• generating a reproducible build;
• deploying to a test environment;
• controlled validation before production;
• a procedure for rolling back to the previous version.

The goal isn’t to automate every action from day one. Above all, the provider must be able to explain its process, its controls and how it handles a failed deployment.

Evidence to ask for:

• an anonymized example of a pipeline;
• the list of checks run automatically;
• a walkthrough of the deployment process;
• the procedure planned in case of an incident.

Question to ask:

What concretely happens when an automated test fails in the pipeline?

Warning sign:

Deployments are performed manually by a single person, with no documented procedure and no rollback option.

3. A stable, well-led team

Turnover is one of the main risks in an outsourced collaboration. A developer’s departure shouldn’t cause a significant loss of knowledge or block deliveries.

In particular, assess:

• the seniority of the profiles proposed;
• the average tenure of staff;
• the presence of a clearly identified tech lead;
• how mentoring and code reviews are organized;
• knowledge sharing;
• the replacement or reinforcement arrangements;
• the number of projects staff work on simultaneously.

Evidence to ask for:

• the actual team composition;
• each person’s roles and responsibilities;
• the onboarding process for a new team member;
• the continuity plan for critical skills.

Question to ask:

How do you ensure project continuity if a key profile leaves the team or becomes unavailable?

Warning sign:

A team that looks attractive on paper, but relies mainly on junior profiles or on a single senior developer.

4. Governance based on reliable information

A good provider doesn’t just execute the tickets it receives. It must also make project progress visible, flag risks and facilitate trade-offs.

The governance setup can include:

• a weekly meeting on deliveries, risks and dependencies;
• a monthly steering committee on budget, quality and the team;
• a prioritized backlog with acceptance criteria;
• a risk register and associated actions;
• a clear procedure for handling scope changes.

Indicators should remain suited to the project. Piling up KPIs is pointless if they don’t support decision-making.

Useful measures include:

• the time between the start of development and its production release;
• deployment frequency;
• the rate of bugs detected after delivery;
• the volume of production incidents;
• the rollback rate;
• mean time to recovery;
• team stability.

Evidence to ask for:

• an anonymized example of a dashboard;
• steering committee minutes;
• an example of a risk register;
• the list of indicators actually tracked.

Question to ask:

How do you make delays, technical risks and quality gaps visible?

Warning sign:

Difficulties are only communicated once they are already affecting deadlines or budget.

5. A real understanding of the product and what’s at stake

The quality of a project doesn’t depend solely on the code. It also relies on the team’s ability to understand the business need.

A relevant partner should be able to:

• question an unclear request;
• propose several options with their trade-offs;
• break a feature down into coherent steps;
• identify dependencies and risk areas;
• build a realistic roadmap;
• raise a flag when a decision needlessly increases complexity.

Evidence to ask for:

• an example of scoping or a specification;
• a well-argued technical decision;
• an example of functional breakdown;
• how developers access the product context.

Question to ask:

Can you give me an example of a client requirement you challenged and explain why?

Warning sign:

The provider accepts every request without questioning its usefulness, feasibility or technical consequences.

6. Security practices built into development

Security shouldn’t be dealt with only at the end of the project.

Even outside a heavily regulated industry, several points should be checked:

• access management based on the principle of least privilege;
• protection and rotation of secrets;
• separation of environments;
• use of anonymized data for testing;
• logging of sensitive actions;
• dependency control;
• consideration of the main OWASP recommendations;
• possible use of SAST or DAST tools depending on the risks.

Evidence to ask for:

• the access management policy;
• the onboarding and offboarding process for staff;
• the rules for storing secrets;
• an example of a security check built into the pipeline.

Question to ask:

How is access revoked when a team member leaves the project?

Warning sign:

Accounts or passwords are shared between several people, or production data is used freely in development environments.

7. A collaboration model that plans for reversibility

Before signing, you need to determine how the collaboration can evolve, but also how it can end.

The contract and day-to-day operations should specify:

• ownership of the code and deliverables;
• the client’s access to repositories and tools;
• documentation requirements;
• regular knowledge transfer;
• the terms for scaling the team up or down;
• the exit procedure;
• how access, data and environments will be handed back.

Reversibility is a good indicator of maturity. A structured provider doesn’t build artificial dependency around the project.

Evidence to ask for:

• a reversibility clause;
• an example of technical documentation;
• a knowledge transfer procedure;
• confirmation that code repositories remain accessible to the client.

Question to ask:

If we end the collaboration in six months, what will you hand over to us and how quickly?

Warning sign:

The provider alone holds the access, documentation or knowledge needed to maintain the product.

The grid for evaluating a provider before you sign

This grid lets you compare several providers on verifiable elements.

Give each criterion a score from 0 to 2:

• 0: absent or not demonstrated;
• 1: partially formalized;
• 2: structured, applied and demonstrated.

Area assessed

0 points

1 point

2 points

Code review

Absent

Done informally

Systematic, documented and enforced

Testing strategy

No defined process

Partial testing depending on the project

Test levels defined according to risk

CI/CD

Manual deliveries

Partial automation

Secure pipeline with checks and rollback

Governance

No structured tracking

Rituals in place but loosely formalized

Responsibilities, risks and KPIs clearly tracked

Security

Handled on an ad hoc basis

A few general rules

Practices built into development and CI/CD

Team stability

No visibility

Continuity partially planned

Lead, documentation and replacement arrangements

Product understanding

Executes requests

Occasional functional discussions

Proven ability to challenge and prioritize

Documentation

Absent or late

Produced irregularly

Updated as the project progresses

Reversibility

Not planned

General clause

Concrete plan for transferring access and knowledge

Transparency

Information shared late

Mostly declarative reporting

Shared access to tools, metrics and risks

How to interpret the result

• 0 to 7 points: the risk is high. The provider doesn’t sufficiently demonstrate the soundness of its organization.
• 8 to 14 points: several foundations exist, but weak areas must be addressed before signing.
• 15 to 20 points: the setup appears structured. It still needs to be verified through a pilot engagement.

This score shouldn’t replace human judgment. Its main purpose is to compare providers against the same criteria and to prevent a polished sales presentation from masking operational weaknesses.

How to test the collaboration before committing long term

Step 1: carry out an initial assessment

This first step lets you check the provider’s maturity based on concrete evidence.

It can include:

• analyzing an existing code repository;
• reviewing testing practices;
• reviewing the CI/CD pipeline;
• assessing how the team works;
• defining an initial governance setup;
• identifying the main technical risks.

The goal isn’t to produce an audit that is excessively long, but to check the consistency between the sales pitch and actual practices.

Step 2: launch a pilot engagement

A pilot engagement of a few weeks lets you assess the collaboration under representative conditions.

The chosen scope should be:

• limited;
• sufficiently concrete;
• measurable;
• connected to how the product actually works;
• delivered to the same standards as future features.

During this period, observe:

• the quality of deliverables;
• delivery on commitments;
• the ability to flag a problem;
• the clarity of communication;
• the team’s autonomy;
• the quality of documentation;
• integration with your internal teams.

A successful technical demo isn’t enough. You also need to check the provider’s ability to work with your organization.

Step 3: scale up gradually

If the pilot engagement is conclusive, scaling up can be gradual:

• adding developers;
• strengthening the tech lead role;
• bringing in a QA tester;
• improving CI/CD;
• formalizing rituals and indicators;
• gradually extending the scope entrusted to the team.

This progression reduces risk and lets you adjust the organization before building a larger team.

Warning signs you shouldn’t ignore

Certain statements should immediately raise questions:

• “Testing takes too much time.”
• “We’ll set up CI/CD later.”
• “We don’t have a lead, but the developers are autonomous.”
• “We ship fast and fix things afterwards.”
• “Documentation isn’t necessary.”
• “We don’t track turnover.”
• “The client doesn’t need direct access to the repository.”
• “We can’t introduce you to the team before signing.”
• “We don’t have any reporting or process examples to show you.”

For confidentiality reasons, a provider won’t necessarily be able to share documents from other clients. It should, however, be able to present anonymized templates, explain its practices precisely and demonstrate that they are not merely theoretical.

Checklist before selecting your IT partner

Quality and engineering

• documented Definition of Done;
• systematic code review;
• risk-based testing strategy;
• operational CI/CD pipeline;
• production release and rollback procedure;
• tracking of incidents and post-delivery quality.

Team

• the profiles actually proposed are identified;
• tech lead and responsibilities defined;
• team tenure and stability known;
• replacement plan in place;
• knowledge transfer organized;
• actual availability of staff verified.

Governance

• follow-up rituals defined;
• backlog and priorities accessible;
• quality and delivery indicators shared;
• risks tracked with associated actions;
• scope changes governed;
• client and provider responsibilities clarified.

Security

• individual, restricted access;
• secrets protected;
• separate environments;
• test data under control;
• dependencies controlled;
• staff departures managed.

Contract and reversibility

• code ownership specified;
• repository access guaranteed;
• documentation included in the deliverables;
• intellectual property addressed;
• exit procedure defined;
• knowledge transfer planned.

Conclusion: ask for evidence, not just promises

Choosing an IT outsourcing provider isn’t about selecting a destination, a rate or a set of résumés. It’s about choosing a delivery system capable of producing consistent quality over time.

QA, CI/CD, governance and documentation practices should be explainable, demonstrable and verifiable before signing.

A pilot engagement then lets you test these commitments against reality: quality of deliverables, transparency, ability to raise alerts, autonomy and integration with your teams.

The right partner is therefore not the one that promises never to run into difficulties. It’s the one with a framework solid enough to detect them early, make them visible and deal with them effectively.

FAQ