How do you test an outsourcing partner before signing a long contract?
Run a paid pilot: a four-to-six week, fully scoped, production-quality piece of work with a fixed price, explicit acceptance criteria, and a written scorecard you agree before the vendor starts. A pilot is not a free trial and not a proof of concept — it is a small commercial engagement whose real purpose is to observe how the vendor works when things go wrong, at a cost you can absorb if the answer is no.
European buyers who skip this step usually pay for it later. References are curated, sales engineers are not the delivery team, and a good proposal document tells you almost nothing about how a vendor handles an ambiguous requirement on a Thursday afternoon. A pilot converts sales claims into evidence.
Why pay for a pilot instead of asking for a free one?
Free trials attract the wrong behaviour on both sides. The vendor staffs a free engagement with whoever is on the bench, treats it as pre-sales rather than delivery, and has every incentive to make it look good rather than be good. You, meanwhile, feel unable to make demands about a piece of work you are not paying for.
A paid pilot changes the dynamic. You can insist on named engineers, contractual acceptance criteria, and access to the delivery process. The vendor allocates real capacity and real accountability. And the cost is a genuine test of your own conviction: if the work is not worth a few weeks of budget, it is not worth a multi-year contract either.
What should the pilot scope actually be?
The scope decides how much you learn. A good pilot scope is small enough to finish, real enough to matter, and awkward enough to be revealing.
| Choose | Avoid | Why |
|---|---|---|
| Work that ships to production | A throwaway prototype | Only production work exposes testing, review and release discipline |
| A feature that touches your existing codebase | A greenfield sample app | You need to see how they read unfamiliar code |
| A requirement with one deliberate ambiguity | A perfectly specified task | How they handle the gap is the most valuable signal |
| Something with a real integration or dependency | An isolated UI screen | Coordination with third parties is where most delivery risk lives |
| Four to six weeks of work for two or three engineers | A two-week sprint or a three-month project | Too short shows nothing; too long is no longer a pilot |
Keep the pilot inside a bounded part of the system so that a poor result does not leave you with technical debt in a critical path. Write the scope with the same rigour you would use for the full engagement — the structure in our guide to writing an outsourcing RFP and scope of work works just as well at pilot size.
What must be in the pilot contract?
- Fixed price and fixed end date. Time and materials removes the vendor's incentive to be efficient at exactly the moment you are measuring efficiency.
- Named engineers, with a continuity clause. The people who do the pilot should be the people who would do the engagement.
- Acceptance criteria written before kickoff. Functional behaviour, test coverage expectation, performance thresholds, and a definition of done.
- Full IP assignment on payment. Whatever the outcome, the code is yours — no lock-in through ownership.
- Data handling terms. A data processing agreement and, if personal data is involved, no shortcuts on residency or transfer mechanics.
- An exit clause with no penalty. Either party can decline to proceed at the end of the pilot without further obligation.
- An explicit no-obligation statement. The pilot does not commit you to the framework agreement.
Do not sign the master services agreement before the pilot. Negotiating it after gives you leverage you will not have again.
What should you actually be measuring?
Score the pilot on a written rubric agreed internally before it starts, so that the final conversation is about evidence rather than impressions. Weight the process signals at least as heavily as the output.
| Signal | What good looks like | Red flag |
|---|---|---|
| Handling the ambiguity you planted | They notice it, ask a precise question, propose an option | They guess silently, or escalate everything |
| Code review quality | Substantive review comments within the vendor team | Approvals with no comments; all review falls to you |
| Testing | Tests written alongside the code, meaningful assertions | Tests added at the end to satisfy a coverage number |
| Communication cadence | Written updates, blockers raised early, questions batched sensibly | Silence, then a surprise at the demo |
| Estimation accuracy | Estimates revised early with reasons | On track, on track, on track, then late |
| Response to critical feedback | Fixes the class of problem, not just the instance | Defensiveness, or fixes only what was named |
| Onboarding speed | Productive within the first week | Still asking for access in week three |
| Security and access hygiene | Least-privilege access, no credentials in chat | Shared accounts, casual handling of secrets |
The measures you use in the pilot should be the measures you later write into the engagement. Our guide to setting code quality SLAs for an offshore team covers how to turn these signals into contractual terms.
How many vendors should you pilot at once?
Two is usually right. One gives you no comparison; three costs more in your own management time than the extra data point is worth. Give both the same scope, the same access, the same brief and the same rubric, and do not tell either that it is a bake-off — you want their normal behaviour, not their competitive behaviour.
Budget your side of it honestly. Two parallel pilots consume real product-owner and senior-engineer time, and if you under-resource your half you will end up measuring your own responsiveness rather than the vendors'. The broader evaluation checklist is in our post on choosing a software outsourcing partner in Europe.
What happens after the pilot?
- Score within a week. Have every participant fill in the rubric independently before discussing it.
- Hold a joint retrospective with the vendor. How they run a retrospective on their own work is itself a strong signal.
- Convert the pilot terms into the contract. Acceptance criteria, continuity clauses and reporting cadence carry over directly.
- Keep the pilot team. Insist that the engineers who delivered the pilot form the core of the engagement.
- Be willing to stop. A pilot that only ever ends in a signature was never a test.
If the answer is no, you have spent a few weeks of budget instead of a year of roadmap — which is precisely what the pilot was for.
Ready to run one?
Write the scope, the acceptance criteria and the scorecard first, then approach vendors with all three in hand. If you want a partner who will engage on those terms, our dedicated engineering team service is set up to start with a fixed-price, production-quality pilot before any long-term commitment.
