Originally published at https://axentis.tech/evaluate-india-software-development-partner/.
Choosing an India software development partner looks simple until delivery starts. Proposals read alike, and sales calls rarely show how ownership, communication and cadence will feel six weeks in. If you are a CTO, founder or VP of Engineering in the US, UK, Canada or Australia deciding how to choose an offshore software development company, use one due-diligence scorecard on every shortlist candidate — including us.
This checklist covers outcome definition, company and contract checks, team continuity, delivery cadence, IP and security, references, red flags, and why a pilot-first engagement beats a long commitment made on slides.
Start with the outcome, not the vendor
Most evaluation processes start with vendor outreach. Flip that. Before you talk to anyone, write down:
- The outcome. What should exist when the first engagement ends? A feature, an integration, a mobile MVP release slice, an assistive AI workflow with human approval, or a DevOps improvement?
- The owner on your side. Who will answer questions, accept work and make trade-off calls? Without a named product owner, even a strong partner will stall.
- Success criteria. How will you know the work is done? Prefer testable statements over vague quality language.
- Constraints. Stack preferences, compliance needs, time-zone overlap windows and hard dates.
That brief becomes the filter. Vendors who cannot respond to a clear outcome with a clear scope are not ready for a serious evaluation. If you are still choosing between engagement models, read our guide on staff augmentation vs project outsourcing before you shortlist.
Company checks: entity, contract, IP and data handling
Ask for paperwork early. You are buying a commercial relationship, not a portfolio of slides.
- Legal entity. Confirm the registered company name, jurisdiction and who signs the master agreement. Match invoice details to the contracting entity.
- IP assignment. The contract should assign work product and related IP to you on payment (or as otherwise agreed in writing). Resist any setup where the partner retains exclusive ownership of code written for your product.
- Subcontracting. Ask whether work can be subcontracted, and whether you get written notice and approval rights if it is.
- Data handling. How will they access your systems and data? Where do environments live? What happens to copies of data at the end of the engagement?
- Confidentiality and security baselines. NDAs, access logging, MFA on shared tools, and a clear rule that secrets never live in source code.
If a vendor postpones these topics until “after we kick off,” treat that as a signal, not a scheduling quirk.
Team checks: who actually writes the code
Sales teams and delivery teams are not the same people. Your due diligence should find the people who will touch your product.
- Named roles. Ask for the roles on the proposed team (tech lead, engineers, QA, designer if needed) and how many hours of overlap they can commit to your time zone.
- Continuity plan. What happens if someone leaves mid-engagement? How is knowledge documented, and how quickly is a replacement briefed?
- Same people after the pilot. If you start with a scoped pilot, confirm that the pilot team is the team you would scale with, not a temporary “best foot forward” cast.
- Working style. Prefer written updates, clear questions and demos of work in progress your product owner can follow — not résumé claims about fluency.
For US, UK, Canadian and Australian teams working with India, agree the overlap window in writing. Morning IST often suits Australia; late afternoon and evening IST often cover UK and US East Coast mornings. Exact hours matter less than showing up for them.
Delivery checks: estimation, acceptance criteria and cadence
Delivery due diligence is about how work becomes visible and how “done” is defined.
- Estimation method. Ask how they break work down, what assumptions they surface, and how they handle uncertainty. Vague ranges with no assumptions are a warning.
- Acceptance criteria before code. Insist on written, testable criteria and an explicit out-of-scope list. This is the same discipline we describe for a paid pilot project.
- Cadence. Agree a weekly rhythm: planning, written progress notes, a demo of work in progress, and a short risk list. You should not need to chase status.
- Visibility. You should see the task board, repositories you control, and builds as they happen — not only a polished end-of-sprint show.
- Change control. New ideas go to a backlog or swap against something else. Unlimited “while you’re in there” work destroys both schedule and trust.
Match the delivery shape to the outcome type. A custom software feature, a mobile MVP release slice, an assistive AI/ML workflow with human approval, or a DevOps and SRE readiness improvement each needs different acceptance tests — but the same transparency rules apply.
Ownership checks: repositories, clouds and credentials from day one
Vendor lock-in rarely starts with a hostile clause. It starts with code sitting in accounts you do not control.
- Client-owned repositories from day one, with your organisation as the owner and the partner as collaborators.
- Cloud and hosting accounts in your name, or transferable with a documented process you have rehearsed.
- Credentials and secrets stored in your vault or account, rotated on handover, and never shared in chat.
- Documentation that travels. Architecture notes, setup steps, runbooks and decision logs short enough that a new engineer on your side can continue the work.
A partner who is confident about handover will welcome this setup. A partner who resists it is telling you something important about the relationship they want.
Security and references without theatre
Security due diligence does not require a multi-day audit for a first engagement, but it does require basics you can verify:
- Who has access to production and staging, and how that access is revoked.
- Whether secrets are kept out of repositories and CI logs.
- How dependency updates and vulnerability triage are handled during the engagement.
- What happens to your data copies when the engagement ends.
On references, ask for buyers who ran a comparable engagement. Did the people on the call match the people who delivered? How did they handle bad news? Was ownership clean at the end? Treat vague praise as soft evidence; treat specific, mixed feedback as useful. Do not treat public code portfolios as proof of delivery quality — process and ownership under your acceptance criteria matter more.
Red flags that should stop or slow a deal
Walk carefully — or walk away — if you see several of these:
- Refusal to put IP assignment, ownership of repositories or data-handling terms in writing before kickoff.
- A team that will not name who does the work, or that swaps people without notice.
- No willingness to write acceptance criteria or an out-of-scope list.
- Status only available in sales meetings, with no access to work in progress.
- Pressure for a long exclusive commitment before any shared delivery experience.
- Vague claims about AI acting without human approval. Prefer assistive designs where people review and approve external actions.
- Time-zone overlap promised in the pitch and missing in the first two weeks.
One missed item can be fixed. A pattern of evasion usually cannot.
Test the relationship with a pilot-first engagement
The highest-signal due-diligence step is simple: run a small, paid, scoped engagement before a long contract. A pilot lets you judge communication, estimation honesty, engineering hygiene and handover on real work — not on a pitch.
At Axentis, that structure is Launch Pilot: private scoping, written acceptance criteria, client-owned repositories from day one, agreed overlap for US, UK, Canadian and Australian teams, and a clean decision at the end (scale, adjust or stop). For AI work, use the same discipline as how to scope an AI pilot: one workflow, a baseline, human approval and a go / extend / stop gate. Apply this checklist to Axentis the same way you apply it to anyone else.
FAQ
What should I ask an offshore software development company first?
Start with outcome, ownership and process: What exactly will be delivered, who owns the repositories and IP, how will acceptance criteria be written, and what overlap hours will the delivery team keep with your time zone?
How long should due diligence take before signing?
Long enough to complete company, team, delivery and ownership checks, plus at least one reference conversation. Many teams then run a short paid pilot as the final filter rather than stretching paper diligence indefinitely.
Is a paid pilot better than a long fixed contract for a first engagement?
Usually yes, when you have not worked together before. A pilot bounds cost and risk while testing real collaboration. A longer contract makes more sense after you have seen delivery, not before.
What if the partner is in India and my team is in the US, UK, Canada or Australia?
Agree overlap hours in writing, lean on async written updates and recorded walkthroughs for everything that does not need a live call, and judge the partner on whether blockers get raised early rather than overnight silence.
Ready to run this checklist with Axentis?
If you are shortlisting an India engineering partner and want a bounded first outcome rather than a leap of faith, talk to an expert. We will walk through your brief against this same checklist and, if there is a fit, scope a Launch Pilot around your acceptance criteria and timeline.
If you are planning a first engagement, see how a scoped Launch Pilot from Axentis works, or read more product and engineering notes on the Axentis blog.
Top comments (0)