How to Vet an Indian Software Development Company: A Checklist for US Buyers

Step 1: confirm who you are contracting with

Start with the company register. India's Ministry of Corporate Affairs publishes company master data you can search by company name or Corporate Identification Number (CIN). It shows whether the company is active, when it was incorporated, its registered office and its directors.

Check that:

• The legal name on the proposal matches the register exactly, including "Private Limited" or "LLP".
• The company status is active, not struck off or in liquidation.
• The directors include the people you are negotiating with, or the vendor can explain the relationship.
• Invoices and bank details are in the company's name. Never pay a personal account.

Your accounts payable staff will probably ask the vendor for Form W-8BEN-E rather than a W-9, because the payee is a foreign entity. The IRS instructions for Form W-8BEN-E explain that the vendor gives the form to you, the payer, and does not send it to the IRS. Ask your tax adviser how it applies to your payments; an established vendor will usually have one ready.

Step 2: inspect shipped work you can open yourself

A portfolio page proves only that someone built a portfolio page. Ask for work you can use:

• Live URLs and app store listings, with a demo login where the product is not public.
• A walk-through of one project's repository structure, deployment pipeline and issue tracker, with client details redacted.
• Who built which part. Agencies sometimes subcontract, and you want to know whose developers would sit on your project.
• A reference call with a past client, accepting that some clients sit behind NDAs and cannot speak.

Warning signs: logos with no links, case studies with no product names, reviews you cannot trace to a real person, and "results" with no source.

Step 3: test the people, not the pitch

The sales lead will not decide whether your project succeeds. Before signing, ask to meet the technical lead and at least one developer who would work on your code. Then test them:

• Give them a small, real problem from your project and ask how they would approach it. Listen for questions about your users and your data, not just a framework name.
• Read a sample of their written status updates or tickets. Most of your communication will be written, so clarity on the page matters more than polish on a call.
• Ask what happens if a developer leaves mid-project, and how knowledge is kept in documents and code reviews rather than in one person's head.
• Ask how they estimate, and what they do when an estimate turns out wrong.

Step 4: work out the time zones before you need them

India runs on UTC+5:30 all year and does not observe daylight saving time. US Eastern is UTC−4 until the first Sunday in November and UTC−5 after it, so in October India is 9.5 hours ahead of New York, and from November 1, 2026 it is 10.5 hours ahead. US Pacific adds three more hours: 12.5 hours in October and 13.5 after November 1.

In practice, a 9:00 a.m. Eastern call lands at 6:30 p.m. in India in October and 7:30 p.m. after the clocks change. A workable rhythm looks like this:

• One fixed overlap window a day, usually your morning and the vendor's evening.
• Written daily updates on a shared board, so your morning starts with yesterday's progress.
• A demo of working software every two weeks, on a staging server you can click through yourself.
• An agreed response time for production issues, and a named person who answers.

The gap can work in your favor. Work you hand over at the end of your day can be done by your next morning, but only if requirements are written clearly enough to act on without a call.

Step 5: ask hard questions about security and data

You do not need a formal audit to have a useful security conversation. NIST's Secure Software Development Framework (SP 800-218) gives you a good vocabulary. Ask:

• Who reviews code before it merges, and is that enforced in the repository settings?
• How are third-party libraries checked for known vulnerabilities, and how often?
• Where are secrets such as API keys stored, and who can read them?
• Who has access to production, is it limited by role, and is multi-factor authentication enforced?
• Where will your data be stored, and will developers work on copies of real customer data or on test data?

If a vendor claims a certification, ask for the certificate itself and check it with the body that issued it.

India's Digital Personal Data Protection Rules were notified on November 14, 2025, with compliance phased in over 18 months. Ask the vendor how it is preparing, and remember that your own obligations, such as state privacy laws or HIPAA if you handle health data, travel with your data wherever it is processed.

Step 6: read the contract for ownership and exit

Have your attorney review the agreement, and make sure it covers:

• IP assignment: all code, designs and documents assigned to your company on payment.
• Repositories in your name: source code lives in your GitHub, GitLab or Bitbucket organization from the first commit, not handed over at the end.
• Accounts in your name: cloud hosting, domains, app store developer accounts, analytics and third-party APIs registered to your company.
• NDA: signed before you share anything sensitive.
• Acceptance criteria and milestones: payments tied to working software you have tested, not to elapsed time.
• Termination and transition: what the vendor hands over, how fast, and at what cost if you leave.
• Governing law and dispute resolution: a venue and method you could realistically use if something goes wrong.

• A price far below every other bid with no explanation of how it is possible.
• No written scope before a request for a large deposit.
• Refusal to work in your repository or to register accounts in your name.
• One person acting as sales lead, project manager and sole developer on a large build.
• Requests to pay a personal account or a differently named company.
• Certifications or partner badges with no certificate behind them.
• Pressure to sign this week to keep a discount.

DipanshuTech Solutions Pvt. Ltd. is a software company in Greater Noida, India, with 10+ years of work, 963+ projects delivered, 63+ developers, and projects across 20+ industries and 15+ countries. More about us is on our company page.

Our case studies describe products we built, most of them for the Indian market and several of them live. ERPSetu, a rentable ERP, has run at erpsetu.in since September 2026, and Takshiva, a school ERP, has been live at takshiva.com since August 2026. We do not have US client names to share, and we would rather say so than imply otherwise.

On process: we work over video calls and a shared project board, send a written scope and a fixed quote after discovery, put working software on a staging server every two weeks, keep source code and accounts in your company's name, and sign an NDA on request.

What documents should an Indian software company provide before signing?

A proposal with its full legal name and CIN, a written scope, a draft contract with IP and exit terms, and, when you pay, the tax form your finance staff need, usually a W-8BEN-E.

How many hours of overlap can we expect?

That depends on the hours the vendor commits to. A common pattern is two to three hours of your morning against the vendor's evening. Agree the window in writing and keep most updates asynchronous.

Who owns the code we pay for?

Whoever the contract says. Insist on assignment of all IP on payment, and on code living in your repository from day one, so ownership never depends on a handover.

Should we start with a small paid project?

Yes. A paid discovery or a small first phase shows you how a vendor writes, estimates and ships before you commit the full budget.

If you are shortlisting vendors, put us through this checklist. Start a conversation and ask us every question on the list.