How to Evaluate an India-Based Transformation Partner

Rising onshore developer rates in the US and UK are pushing more SMEs to look at India again. That's not new. What's different this time is that the buyers doing the looking have often been burned before, by a partner who looked capable on a call and then disappeared into unexplained delays once the contract was signed.

So the instinct is to treat distance as the risk. It isn't. You can watch a demo, review a portfolio, and check a company's registration from anywhere in the world. What you cannot see from a video call is how a team actually makes decisions once you're not in the room: who decides that a requirement has changed, who decides what "done" means, who decides whose fault a delay is. That's the part most due-diligence checklists skip, and it's the part that decides whether the next twelve months go smoothly or badly.

What three things should you actually check before signing?

Three things, checked properly, tell you more than a reference call ever will: how they run discovery before quoting, who owns the code once it's written, and how they price change requests after the contract starts. Each of these is a decision point. Ask who makes that decision, not just what the policy says.

How do they run discovery, before they've quoted you anything?

A vendor who gives you a fixed price and a delivery date within 48 hours of the first call has not understood your business. They've matched your feature list to a template they've built before. That might work if your process is genuinely simple. For most manufacturing, distribution and services businesses, it isn't.

A partner worth working with will ask to see how you currently do the thing you want to digitise, before they tell you what it will cost. That means a conversation with the person who actually does the work, not just the person who requested the software. It means questions like: who approves this today, what happens when they're not available, what's the workaround people use when the system doesn't cover a case. Discovery that skips this and goes straight to a Gantt chart is discovery in name only.

Ask to see a discovery document from a past engagement, with client details removed. If they can't produce one, they don't run discovery. They run quoting.

Who owns the code, and when does ownership actually transfer?

This is the clause most buyers skip because it feels like a legal formality rather than a business risk. It isn't. If the contract is silent on intellectual property, or vague about when ownership passes to you, you are building your operating system on someone else's asset.

The question to ask directly: at what point, contractually, does the code become mine? Some firms transfer ownership only on final payment, which is workable but leaves you with no leverage if the relationship sours mid-project. Better firms transfer ownership per milestone, in writing, so you own what you've paid for as you go. Get this clause read by your own lawyer, not the vendor's, before you sign anything.

How are change requests priced once the contract is signed?

This is where good relationships turn sour, and it's almost always avoidable. Every project changes scope. The business doesn't stop moving just because the brief was frozen in month one. What matters is not whether change happens, but whether the pricing for it was agreed before it happened.

Ask for their change-request model before you sign the main contract, not after the first change lands. A day-rate, a point-based system, a tiered pricing table for small versus large changes, any of these work if they're written down and agreed in advance. "We'll sort it out as we go" is not a pricing model. It's a way of keeping the conversation vague until they have leverage.

If the answer to "what will this change cost" needs a phone call every time, it's not a system. It's a negotiation you'll be having every month for the life of the contract.

What does this look like in practice?

Consider a US-based distribution company evaluating two India-based firms for a warehouse management rebuild. Firm A quoted a fixed price and an eight-week timeline after a 45-minute call. Firm B asked for two weeks of paid discovery: shadowing the warehouse team, reviewing how discrepancies between physical stock and system stock currently get resolved, and who signs off on write-offs.

Firm A's quote was roughly 30% lower. Firm B's discovery surfaced that the real problem wasn't the software; it was that three people could approve a stock adjustment and none of them checked each other's work. Building a system on top of that would have digitised the confusion, not fixed it.

The owner's decision here isn't which quote is cheaper. It's whether they're buying a system or buying a template. That decision gets made in the discovery phase, before a line of code is written, and it's the one thing a reference call from a past client won't tell you, because the past client's process wasn't yours.

How do these checks compare in practice?

Area	Red flag	Green flag
Discovery	Fixed quote within 48 hours of the first call	Two-to-four week discovery producing a written scope document
Code ownership	Contract silent on IP transfer	Explicit clause: ownership transfers per milestone, before final payment
Change requests	"We'll figure out pricing as we go"	Published day-rate or tiered pricing for changes, agreed before work starts
Communication	One contact person, unreachable outside scheduled calls	Documented decision log you can check without a call
References	Only glowing testimonials offered	Willing to connect you with a client who had a rough patch

What should you ask on the first call?

Ask these three questions directly, and listen for how specific the answer is, not just what it says.

1. "Walk me through how you'd run discovery for this project, before you'd give me a number."
2. "At what point does the code you write for us legally become ours?"
3. "If I ask for something outside the original scope in month three, how does that get priced?"

A partner who has done this before will answer in specifics: named documents, named clauses, named pricing structures. A partner who hasn't will answer in reassurance: "don't worry, we'll take care of you." Reassurance is not a system, and it's not something you can hold anyone to six months in.

This is the same principle we work from before writing a line of code for any client: we understand how your business actually works first — then we design the system. If a partner can't describe how they'd do that for you specifically, distance isn't your biggest risk. Vagueness is.

What to do next

Send these three questions to the partners you're already evaluating, in writing, and ask for written answers. Don't accept a call in place of a written answer. If a firm can produce a real discovery document, a clear ownership clause and a change-pricing table without hesitation, distance stops being the issue you're solving for. If they can't, no reference call or portfolio review will fix what's actually missing.

For a longer look at how to structure the engagement itself once you've chosen a partner, see our guide to choosing and working with a transformation partner, and if you want to see how we run discovery before quoting, visit our transformation partner services page.