Most offshore engagements that go wrong do not go wrong on skill. They go wrong on ownership, on communication, and on what happens in month seven — long after the part everyone evaluated carefully.
We are an Indian company that builds software for clients elsewhere, so we have an obvious interest in you hiring an offshore team. Take the questions below in that light. They are the ones we would ask if we were on your side of the table, including the two that are least comfortable for us to answer.
"Who exactly will write this, and will they still be here in six months?"
The people in the pitch are not always the people on the keyboard. This is the single most common gap between what an offshore engagement looks like when you buy it and what it is when you run it.
Ask for names, not headcount. Ask what else those people are working on this quarter. If the answer is a role — "a senior engineer and two mid-level" — rather than individuals, you are buying capacity from a pool, which is a legitimate model but a very different one. Pooled capacity is fine for well-specified work and poor for anything that depends on accumulated context about your business.
The follow-up matters more than the question: what happens when one of them leaves? Every firm loses people. The ones worth hiring have an answer that involves written-down decisions rather than a promise it will not happen.
Every firm loses people. The ones worth hiring have an answer that does not depend on not losing them.
"What hours will we actually overlap?"
Not "we are flexible". A number.
India is 9.5 to 12.5 hours ahead of the United States depending on your coast and the time of year. That gap can work in your favour — you hand off at the end of your day and there is progress by morning — but only if someone has deliberately designed for it. Done badly, every question costs a full day.
Ask which hours are guaranteed overlap, who is available in them, and what the path is for something urgent outside them. Then ask how many of their current clients are in your timezone. A team that has never worked US hours will tell you they can; a team that already does will tell you how.
"Show me something you shipped that is still running."
Shipping is easy to demonstrate. Running is not.
A portfolio shows launches. What you want to know is whether anything they built survived contact with real use — whether they were still maintaining it two years later, what broke, and what they changed as a result. Software that has been live for three years has been patched, migrated, and argued about. That history is where you learn how a team actually works.
If every reference project ended at launch, you are looking at a team optimised for delivery, not for ownership. That may be exactly what you want. Know which one you are buying.
"What will you refuse to do?"
A partner who agrees to everything in the sales conversation will agree to everything during the project, including the things that should have been pushed back on. That is not accommodating; it is expensive.
Ask for an example of a time they told a client no, and what happened. Ask what they think is a bad idea in your brief. If they cannot find anything wrong with a plan they heard about an hour ago, they are either not listening or not saying.
"Who owns the code, the repositories and the infrastructure?"
This should be boring and it frequently is not.
The answer you want: you own the code from the first commit, it lives in your organisation's repositories, and the cloud accounts are in your name with the vendor given access. Anything else — code delivered as a zip at the end, repositories under the vendor's account, infrastructure on the vendor's billing — converts a supplier relationship into a dependency.
The same applies to third-party accounts. If your payment provider, your mail sender and your error tracking are registered to the agency, you do not control your own product.
"What does the handover look like if we stop working together?"
Ask this in the first conversation, not the last. The answer tells you how the work will be done throughout.
A team that expects to hand over writes things down as it goes: decisions, the reasoning behind them, how to run the thing locally, what the known weak points are. A team that does not will produce documentation at the end, from memory, under time pressure, which is worth very little.
The two uncomfortable ones
"What is your actual rate, and what is not included?" Offshore pricing is usually quoted as a blended hourly or monthly rate. What is often outside it: project management, QA, DevOps time, meetings, and the post-launch period. A low headline rate with four excluded categories is not cheaper, it is less legible.
"What goes wrong on projects like ours?" Everyone has a pattern of failure. Ours is that we would rather build something properly than quickly, which on a deadline-driven project is a real cost to the client and not only a virtue. A partner who cannot name their own failure mode has either not looked or will not tell you.
What none of this tells you
These questions surface process, ownership and honesty. They do not tell you whether a team can build the specific thing you need, and no conversation will. The only reliable test is a small, real, paid piece of work with a defined outcome — something genuinely useful to you, small enough that being wrong is survivable.
Two to four weeks of actual work tells you more than any number of calls: how they handle an ambiguous requirement, whether their estimate meant anything, what the code looks like when nobody is watching, and whether working with them is pleasant. That last one is not a soft consideration. You may be doing this for years.
If you are asking us
We will answer all of the above directly, including the uncomfortable ones, and we would rather lose a project at the question stage than halfway through it. If you want to start with a small paid piece of work rather than a commitment, that is usually the right way round.