Most vendor calls reward whoever rehearsed best. These twelve questions ask for names, documents and decision rules instead, and those are much harder to rehearse.
Why the usual questions fail
Ask ten offshore development partners whether they work in an agile way, communicate transparently and provide a dedicated team, and all ten will say yes. Those questions are not wrong. They just have one acceptable answer, so the answer tells you nothing.
After three calls like that, the shortlist is still a list of hourly rates, and the rate says little about how a project will actually run.
A question gets an honest answer when the vendor cannot give it without drawing on how they really work. That means asking for one of three things: a named person, a document that already exists, or a rule with a number in it. A team that works this way answers in a sentence. A team that does not work this way has to improvise, and improvising sounds different.
Questions that get evidence
- Who, by name, writes code in the first month?
- Can I see yesterday's handoff note?
- How many working days before an open question escalates?
- What was your part in a project that failed?
Questions that get a pitch
- Do you have experienced developers?
- How do you handle communication?
- Are you responsive?
- How do you ensure quality?
Each question below comes with what an evasive answer usually sounds like and what a real one contains. What you are listening for is whether the vendor is describing a habit or inventing one on the call.
Who does the work
1. Who, by name, will write code on my project in the first month, and can I talk to them before I sign?
The people you meet during a sales process and the people who open your repository are often not the same. This question closes that gap before it costs you anything.
Evasive: "We'll assemble the right team once we understand your requirements."
A real answer gives names and roles, and says which of those people you can speak to this week. It tells you who assigns engineers to projects and whether you have a say when someone is moved.
Listen for the rule on swaps: no one on the named team is reassigned without your written agreement, and a replacement works alongside the outgoing engineer before taking over. Ask how many working days that overlap lasts. If it is fewer than five working days, the context is leaving faster than it is being handed over.
If the names are "to be confirmed," ask what has to happen before they are confirmed, and by when.
2. When did an engineer last leave one of your projects partway through, and what did that client lose?
Every engineering team loses people. This question tests whether the vendor has ever looked closely at what a departure cost the client, or only at how quickly the seat was filled.
Evasive: "Our retention is very strong," or "That doesn't really happen with us."
A real answer describes an actual departure and names what left with that person: a week of momentum, the reasoning behind a design decision, an agreement with the client that only ever lived in one engineer's head. The answer should end with what the vendor changed afterwards.
This is uncomfortable to answer honestly, and it should be. The vendor who tells you about a real loss sounds worse on the call than the one who says it never happens, and may lose your business for it. Treat "never" as the answer that needs the most checking, because the first time you can verify it is during your own project.
How work moves between you
3. Can I see the note someone on your team wrote at the end of yesterday?
Handoffs decide whether a distributed team keeps moving overnight or loses a day to a question nobody wrote down. A handoff is either a habit with a fixed shape or it does not exist, and asking to see one tells you which.
Evasive: "We use Slack and Jira, so everything is visible to you."
A real answer is an actual document, redacted if it has to be: an end-of-day note, a pull request description, a comment on a ticket. It has the same shape every day. It says what changed, what is blocked and by whom, and the one question that needs an answer before the next working day starts, addressed to a named person.
If there is nothing from yesterday, ask for last week. If there is nothing at all, you have your answer.
4. When a requirement is ambiguous, who decides, and how long does the question wait?
Ambiguity is where offshore work quietly goes wrong. Either the team stops and waits, or it guesses and keeps going, and both are expensive when nobody knows which one happened.
Evasive: "We always clarify with the client."
A real answer separates two kinds of decision. The tech lead makes reversible decisions, such as a field name or the layout of an internal admin page, without waiting, and writes the assumption into the ticket so you can overturn it. Irreversible decisions, such as a data model, a permissions rule or anything your customers will see, wait for you.
Then it gives you a clock. An open question with no answer after one working day goes to a named person on your side. After two, the affected work stops, and the team tells you so in writing rather than letting you discover it at the next demo.
5. How will I find out something is slipping, and how many working days before the date?
This question tells you whether bad news reaches you early, while there are still choices, or at the demo, when there are not.
Evasive: "We send weekly status reports."
A real answer names a trigger rather than a calendar slot: the moment an estimate is overrun, or a dependency is still open on an agreed day, someone raises it. It says who raises it, in what written form, and the minimum notice you get, counted in working days before the milestone.
Five working days is a reasonable floor to hold a vendor to; a warning that arrives the day before is a report of something that already happened. A real answer also says what the vendor will ask of you when it happens: cut scope, move the date, or make the decision that has been waiting.
What counts as done, and as yours
6. What has to be true before you call a ticket done?
"Done" is where quality is either written down or assumed, and the assumptions are what surface in production.
Evasive: "It's done when it passes QA."
A real answer shows you a written definition of done, and the engineer on the call can walk through it without reading from it.
It covers five things:
- The change has been reviewed by someone other than its author
- Tests at an agreed level pass in CI, not just on one laptop
- It runs in an environment you can open yourself
- Documentation or migration notes are updated where the change needs them
- A named person, usually on your side, has accepted it against the ticket
Listen for where testing sits in the answer. A vendor that treats testing as part of the engineering work describes it inside every ticket, not as a phase that starts when development ends.
7. From day one, whose name is on the repository, the cloud account and the domain?
Ownership is almost free to set up in the first week. In month eight it is slow and awkward to recover.
Evasive: "Of course you own the code."
A real answer says your organization creates and owns the repository, the cloud accounts, the app store accounts and the domain before the first commit, and invites the vendor in with the access each person needs. Credentials live in your password manager or secrets store, not theirs. When someone leaves the project, removing their access is a checklist item that same day, not a request you have to chase. If the vendor offers to "set everything up and transfer it later," ask what "later" means and what triggers it.
Your calendar against theirs
8. Which weeks of the year is your team not working, and when would I find out?
A holiday week you did not know about has a way of landing on a release.
Evasive: "We're flexible around your schedule."
A real answer is the vendor's own calendar, named. For a team in Nepal, Dashain and Tihar are the longest holiday stretch of the year. They fall in the autumn and follow the lunar calendar, so the dates move every year. Ask when you will see next year's dates and how work is planned around them.
Ask about the working week too, and do not assume it. Nepal's government moved its own offices and educational institutions to a Saturday-and-Sunday weekend in April 2026, replacing a Saturday-only weekend1, and that decision does not set a private company's week. Our own team in Kathmandu works Monday to Friday: the same days as yours, not the same hours.
9. What happens to my work between the end of my day and the start of my next one?
For a US team, the whole arrangement rests on this question. Nepal runs on UTC+05:45 all year, with no daylight saving, so a 10:00 to 18:00 working day in Kathmandu, for example, ends at 8:15 in the morning in New York during daylight saving time. What that means for US teams is worth reading before the call. Outside the US the answer changes: a Kathmandu day covers most of the working day in the UAE and Saudi Arabia, and the morning in the UK and Germany.
Evasive: "We'll align our hours with yours."
A real answer does not pretend the time difference away. It tells you whose working hours move, if anyone's, by how much, and how long that person has actually kept to it. It describes what you find when you open your laptop: the handoff note from question 3, work you unblocked the afternoon before now finished, and a short list of questions waiting for you. It also tells you what happens when something blocks the team while you are asleep: which decisions they may make and write down, and which ones wait a full day for you.
What happens when it goes wrong
10. What kind of project should we not hire you for?
A vendor that is a good fit for every project has not thought hard about fit, and your project is about to become the test.
Evasive: "We're full-stack. We can handle anything you need."
A real answer names a kind of work, a stack or a way of working the vendor would turn down, and explains why. It might be a stack the team has not shipped to production before, a product that needs engineers in the room with users every day, or a company that makes most decisions in hallway conversations and expects answers within the hour.
The uncomfortable part is that the honest answer might describe your project. The vendor giving it knows that and says it anyway, on a call it may lose because of that answer. If what you hear sounds like your project, believe it.
11. If we stop working together, what do I have on the last day?
How a vendor describes the exit tells you how it thinks about the engagement while it is still running.
Evasive: "We'd make sure the transition is smooth."
A real answer starts from question 7: everything is already in your accounts, so the only thing left to hand over is knowledge. Then it lists what that knowledge looks like on paper:
- A runbook for deploying and rolling back
- A record of the architecture decisions and the reasons behind them
- The open questions and known problems, written down
- A handover period counted in working days, with named people on both sides and an agreed last day for access
Ask how long that handover period is. For anything beyond a small system, fewer than ten working days is a warning sign: much of what the team knows walks out with them.
12. Tell me about a project that went wrong. What was your part in it?
Any vendor can describe a project that failed. What is rare is hearing one name its own share of the failure.
Evasive: "The client kept changing the requirements," or "The client stopped responding."
A real answer gives the vendor's part plainly: an estimate it knew was optimistic and did not challenge, a risk it saw and raised too softly, a question it should have asked in week two and asked in week eight. It ends with what the vendor does differently now.
Expect this to be the most awkward minute of the call, and know that a vendor who answers it well may still lose the deal on it. A vendor that cannot name its part in a past failure is unlikely to name it during yours, which is exactly when you will need it to.
The call script
Copy this into your notes before the call.
Send question 3 ahead, and only question 3
Ask the vendor to bring a real handoff note, redacted if needed. Every other question works best unprepared.
Ask to see before you ask to hear
On questions 3, 6 and 7, ask for the note, the checklist or the account setup before the explanation. A description is easier to judge once you have seen the thing it describes.
Write down names, numbers and admissions
For every answer, note any named person, any number of working days, and anything the vendor admitted was hard. Those three things are what you compare across vendors afterwards.
Follow up once on anything vague
"Can you give me an example from the last month?" is enough. A second vague answer is an answer.
Save questions 10 to 12 for last
By then the call has a rhythm, and the uncomfortable questions land as part of it rather than as an ambush.
The questions, in order:
- Who, by name, will write code on my project in the first month, and can I talk to them before I sign?
- When did an engineer last leave one of your projects partway through, and what did that client lose?
- Can I see the note someone on your team wrote at the end of yesterday?
- When a requirement is ambiguous, who decides, and how long does the question wait?
- How will I find out something is slipping, and how many working days before the date?
- What has to be true before you call a ticket done?
- From day one, whose name is on the repository, the cloud account and the domain?
- Which weeks of the year is your team not working, and when would I find out?
- What happens to my work between the end of my day and the start of my next one?
- What kind of project should we not hire you for?
- If we stop working together, what do I have on the last day?
- Tell me about a project that went wrong. What was your part in it?
Questions buyers ask about vetting
How many offshore vendors should I interview?
At least two, so you have answers to compare against each other. The script works the same way with more, but the notes are only useful if you ask every vendor the same twelve questions.
Should the vendor's engineers be on the call, or only sales?
Ask for at least one engineer who would work on your project. Questions 3, 4 and 6 are about daily practice, and the person who does the work answers them differently from the person who sells it.
What if a vendor refuses to answer one of these questions?
Ask why. Some material is genuinely confidential, and a vendor can say so and offer a redacted or recreated example instead. A refusal with no reason and no alternative tells you more than most answers would.
Republica, "Govt sets new office hours from 9 AM to 5 PM," 5 April 2026. The decision applies to government offices and educational institutions.
↩