Hiring a software development partner in India: a buyer’s checklist

Start with a clear scope

A partner can only estimate and plan what you have described. Before you ask for proposals, write a short brief. It does not need to be technical. It should explain the problem, who will use the software and what a successful first version looks like.

Separate what must be in the first release from what can wait. A smaller first release is easier to estimate, test and accept. It also shows you quickly how the partner works.

• The business goal and the users, in plain language.
• The main tasks each type of user must be able to do.
• Systems the software must connect to, such as payments, a CRM or accounting software.
• Where it will run, and whether you already have cloud or hosting accounts.
• Any rules you must follow on data, accessibility or record keeping.
• Your preferred launch date and the reason for it.

What a good written proposal contains

A proposal is the first real sign of how a partner thinks. A good one restates your problem in its own words and is specific about what is included and what is not. Look for these items:

• Scope: features and deliverables, with exclusions stated clearly.
• Assumptions: what the partner is relying on, such as your content, third-party access or prompt feedback.
• Milestones: what will be delivered at each stage and how you will check it.
• Timeline: realistic, with dependencies on your side named.
• Fees and payment terms, tied to milestones rather than dates alone.
• Change process: how new requests are estimated and approved.
• Ownership, confidentiality and handover terms.
• Support after launch: what is covered, for how long and how to report issues.

Milestones and acceptance

Break the work into milestones that each produce something you can see and test, such as a clickable prototype, a working feature on a test environment or a production release. Avoid milestones like “50% of development”, which cannot be checked.

Agree acceptance criteria for each milestone before it starts. Keep them simple: the feature works as described, on the agreed devices and browsers, with the agreed test data. Set a fixed review window and say what happens if you find defects. Most teams fix defects found during acceptance as part of the milestone, and treat new ideas as change requests.

Ask to see work in progress regularly, not only at the end of each milestone. Early demos catch misunderstandings while they are still cheap to correct.

Code ownership, IP and access in your name

Do not assume you own the code because you paid for it. Copyright rules differ between countries, and the default position for commissioned work is not always what clients expect. In the UK, for example, a transfer of copyright needs a written, signed document, often called an assignment. Your contract should say clearly that the code, designs and documentation created for you are assigned to your business, and how any open-source or pre-existing components are licensed.

Keep the keys to your own systems. The partner should work inside accounts you control, with access you can remove at any time.

• Code repository, cloud accounts, domain, app store and analytics accounts held in your organisation’s name.
• Named user accounts for each developer, never shared passwords.
• Multi-factor authentication switched on for every account with admin rights.
• Least-privilege access: each person gets only what their role needs.
• Secrets such as API keys stored in a password manager or secrets service, not in code or chat messages.
• A written list of who has access to what, updated when people join or leave.

Communication rhythm

Agree how you will work together before the first sprint. A predictable rhythm matters more than the number of meetings. Many teams use a short written update each working day, a weekly call to review progress and risks, and a demo at the end of each milestone.

Decide where conversations and decisions live. Use one ticketing tool for tasks and defects, one channel for day-to-day questions and a shared document for decisions. Name one contact on each side who can make decisions, so questions do not wait. If you are in a different time zone, agree which hours overlap and what can be handled in writing.

Handover documentation

Handover should not be a single meeting at the end. Ask for documentation to be built up as the project runs, and make it part of the final milestone’s acceptance.

• A README explaining how to set up, build, test and deploy the software.
• An architecture overview: main components, data flows and third-party services.
• Environment and configuration notes, with secrets kept out of the documents.
• An inventory of accounts, licences and subscriptions, and who owns each.
• Runbooks for routine tasks such as releases, backups and restoring data.
• Known issues and suggested next steps.

Red flags

• Promises of certain outcomes, such as fixed search rankings or sales results.
• Vague scope, or a quotation given before the partner has asked any real questions.
• Pressure to pay everything up front, or before any work can be reviewed.
• No written contract, or reluctance to put ownership and confidentiality terms in writing.
• Insistence on hosting your software or data in accounts only the partner controls.
• No access to the code until the final payment, with no interim demos.
• Unclear who will actually do the work, or frequent unexplained changes in the team.

Questions to ask before you sign

1. Who will work on our project, and who is our day-to-day contact?
2. Can you show examples of similar work and explain your role in it?
3. How do you handle change requests and estimate new work?
4. Will all code, designs and documentation be assigned to us in writing?
5. Will you work in accounts we own, using named users and multi-factor authentication?
6. Will you sign our confidentiality agreement or data processing terms if we need them?
7. What are your working hours, and how do you handle urgent issues?
8. What does handover include, and what support is available after launch?

Common questions