Reference calls are theatre. No supplier gives you the number of a client who is unhappy, and the happy ones will tell you the team was "great to work with", which tells you nothing you can act on. Everything below is a check you can run yourself, before money changes hands.
Start by deciding what you are buying
Three engagement models get sold under the same word, and half of all disappointment comes from buying one while expecting another.
| Fixed scope | Lean retained team | Staff augmentation | |
|---|---|---|---|
| Who owns the outcome | Supplier | Shared, explicitly | You |
| Who decides what to build | You, up front | Weekly, together | You |
| Best when | Scope is genuinely stable | Product is still being discovered | You have leadership, not hands |
| Change costs | A change request | A conversation | Nothing, it's your backlog |
| Main risk | Padding, or a fight over scope | Drift without a hard outcome | Nobody accountable for the product |
Write down which of these you are buying before the first call. If a supplier's proposal quietly moves you to a different column, that is the discussion to have.
The five questions that actually discriminate
1. Which named individuals will be on this in month nine, and at what allocation?
Good answer: names, percentages, and what happens if one of them leaves. Bad answer: roles and seniority bands. Suppliers with a bench will rotate people; that is what a bench is for. Make continuity a contractual term with a notice period on team changes.
2. Whose name is on the repository, the cloud accounts and the domain on day one?
It should be yours, from the first commit. If the supplier holds them and hands over "at project completion", you have bought a switching cost. Ask specifically about CI configuration, secrets management and infrastructure-as-code — those are where lock-in hides after the source code has been handed over politely.
3. What is the expected time between a question and a useful answer?
Ask for hours, in writing. Then test it: send a real technical question during the sales process and time the response. You are measuring the loop your whole project will run on. A team in your timezone should be answering inside a working day, and usually inside a few hours.
4. Show me an estimate you got wrong, and what you did about it.
Every supplier with a real delivery history has one. The answer reveals whether estimates come with stated assumptions, whether overruns get flagged early or at the end, and who absorbed the cost. A supplier who claims never to have missed is either new or not telling you the truth.
5. What would make you tell us not to hire you?
A supplier who can name the shape of project they are wrong for is describing a real business. One who is enthusiastic about everything is describing a sales target.
Things to verify rather than ask
- Open their live work. Not case-study screenshots — actual URLs. Click through the flows. Look at load time, error states, mobile layout. This is the single most informative ten minutes in the whole process.
- Read a code sample against a brief you set. Not their showcase repository. Give the same small brief to each shortlisted supplier and compare what comes back — structure, tests, error handling, and whether the README lets you run it.
- Check the timezone claim against reality. Ask what hours the team actually works, including whether the senior people are on a different schedule from the rest.
- Ask how they handle a production incident at 22:00 on a Saturday. The answer is either a described process or an improvisation. Both are informative.
Buy a slice before you buy a project
The strongest evaluation available is a bounded, paid, two-week engagement: one real feature, from your actual backlog, deployed to an environment you control, with the code in your repository.
Define up front what the slice must demonstrate:
- Working software in your environment, not a demo on theirs.
- A written note on what changed, what was assumed, and what they would do differently.
- Direct contact with the engineers throughout, with no relay.
- Handover proof: you can run, build and deploy it yourself after they stop.
Two weeks of real cost buys you more signal than three months of procurement, and if it goes badly you have lost two weeks instead of two quarters.
What good looks like at the end
You should finish evaluation with names, an allocation, a repository you own, a written estimate whose assumptions you have read, and a piece of working software you paid a small amount for. If any of those five is missing, you have not evaluated anything — you have been sold to.
For the model behind this checklist, read nearshore lean software development: what it actually means, and for how the money behaves, what nearshore lean actually costs. If you want to run the two-week slice with us, start here.
A free companion to this piece: our 42-point nearshore lean evaluation checklist — an eight-page PDF covering the team, the commercials, IP ownership, delivery rhythm, engineering practice and the exit. Send it to every supplier you shortlist, including us.
Frequently asked
What should I ask a nearshore development team before signing?
Ask who holds the keyboard in month nine and at what allocation, whose name is on the repository and cloud accounts on day one, what went wrong in their last estimate, and what a bounded two-week paid slice would deliver.
How do I test a nearshore supplier without a large commitment?
Buy a bounded paid slice: two weeks, one real feature, deployed to an environment you control. It tells you more about communication, estimation honesty and code quality than any reference call.
What contract terms protect me in a nearshore engagement?
Day-one ownership of code and infrastructure, named individuals with allocations, a fixed price for a bounded scope, a thirty-day exit with handover documentation, and IP assignment covering every contributor.