How to choose a software development company in India

Outsourced software projects often go wrong before the first line of code is written: a vague scope, a team that changed after the pitch, or a contract that left the code with someone else. This checklist covers what to ask, what to read and when to walk away.

Updated 6 October 20269 min readBy Effred editorial team

Start with a written scope, not a sales call

Before you speak to any company, write a one-page brief: the problem, who will use the software, what the first release must do, the systems it must connect to — your accounting package, payment gateway or HRMS — and the date that matters to the business, such as a festive-season launch or the new financial year on 1 April.

Then ask for a short, paid discovery before any build quote. A week or two of discovery should end with documents you own and could hand to another vendor:

A written scope: the features in the first release, and what is explicitly out of scope.
User journeys and a clickable prototype of the key screens.
An outline architecture: technology choices, hosting, integrations and how data flows.
A release plan with milestones, the assumptions behind the estimate, and the open risks.

Discovery is also the cheapest way to test a vendor: you see how they ask questions, how clearly they write and whether they push back when an idea is expensive. A company that gives a firm fixed price for a complex product after one call has either padded the price or not understood the work.

Keep one scope document that both sides update as things change. It settles arguments that memory cannot.

Find out who will actually work on it

The people in the pitch are rarely the people who write your code. Ask for the named team before you sign — tech lead, developers, tester and delivery manager — and how many other projects each of them is on.

Seniority mix. How many senior, mid-level and junior engineers? A team of juniors supervised by one stretched lead is cheap for a reason.
Your right to interview. Can you speak to the tech lead before signing? A confident vendor will say yes.
Continuity. What happens when someone resigns or moves to another account? Ask how long a replacement overlaps with them, and whether you approve the replacement.
Subcontracting. Will any work go to freelancers or another company? You need to know everyone who can see your code and data.

If you already have a tech lead and just need more hands, adding engineers through staff augmentation is often simpler. Our guide to staff augmentation or a dedicated team covers that choice.

Fixed price, time and materials or a dedicated team

How you pay shapes how the vendor behaves. None of the three common models is always right; each suits a different kind of work.

Model	How you pay	Works best when	Watch out for
Fixed price	An agreed price for an agreed scope, usually paid against milestones	The scope is small, clear and unlikely to change: a company website, a defined integration, a first release with a tight feature list	Every change becomes a priced change request, and a vendor squeezed on margin may cut testing or documentation
Time and materials	Agreed daily or monthly rates for the time actually spent, billed monthly	You expect the scope to change as you learn from users, and someone on your side can set priorities every week	Costs drift without a budget cap, weekly timesheets and progress tracked against the plan
Dedicated team	A fixed monthly fee per person for a team that works only on your product	You have a long roadmap and want the same people to build up knowledge of your product	You pay for the capacity whether or not you use it, so the backlog must always be ready

A sensible pattern is a fixed-price discovery, then a fixed price or capped time and materials for the first release, then a dedicated team or time and materials once the product is live and changing every week.

Whatever the model, ask how the estimate was built. A good one breaks the work into features, shows the effort behind each and lists its assumptions. Compare vendors on the same written scope, and check whether each quote includes GST, licences, hosting and support after launch.

Make sure the code and IP are really yours

This is where Indian law surprises people. Under the Copyright Act, 1957, an employer owns what its employees create in the course of their employment (section 17). The developers on your project are usually the vendor’s employees, not yours, so unless the vendor assigns the rights to you, the copyright in your code can stay with the vendor.

Section 19 sets the rules for handing those rights over. An assignment is valid only if it is in writing and signed. If it does not state a period, it is deemed to last five years; if it does not state a territory, it is presumed to cover India only. A line that simply says “all IP belongs to the client” may not be enough.

Ask for these in the contract, and check them in practice:

A written assignment of all rights in the code, designs and documents made for you — worldwide and for the full term of copyright. Assignment on payment of each invoice is fair.
A perpetual, royalty-free licence to any tools or libraries the vendor already owned and reused in your product.
Code in a GitHub, GitLab or Bitbucket organisation your company owns, from the first commit.
Cloud, domain, app store and other third-party accounts in your company’s name, with the vendor added as a user.
A list of the open-source components used and their licences, so nothing conflicts with how you plan to sell the product.
A handover clause: documentation, credentials and a transition period if either side ends the contract.

This is how we run custom software projects too: the code sits in your repositories from day one.

This guide is not legal advice. Have a lawyer read the IP, liability and termination clauses before you sign.

Security, NDAs and your customers’ data

Sign a mutual NDA before you share anything sensitive, but do not stop there. An NDA tells a vendor what not to disclose. It says nothing about how they protect your systems.

If the vendor will handle personal data about your customers or employees, the Digital Personal Data Protection Act, 2023 applies. You are the Data Fiduciary and the vendor is your Data Processor. You may use a processor only under a valid contract, and you stay responsible for what it does on your behalf (section 8). The DPDP Rules, 2025 set minimum security safeguards — encryption or masking, access control, logs and monitoring, backups, and keeping those logs for a year — and expect your contract with the processor to provide for them (rule 6). Most of these duties apply from May 2027, so contracts signed now should already include them.

Separately, CERT-In’s directions of April 2022 require organisations to report specified cyber incidents within six hours of noticing them. Your contract should oblige the vendor to tell you about an incident quickly enough for you to meet that.

Questions to ask

Who will have access to production systems and data, and how is that access granted, reviewed and removed?
Do developers ever work on real customer data? Test data should be masked or made up.
Is multi-factor authentication switched on for email, code hosting and cloud accounts?
Are laptops encrypted and managed, and what happens to access on someone’s last day?
How do you test for common web weaknesses such as the OWASP Top 10 (opens in a new tab)?
Have you had a security incident? What changed afterwards?

Agree how you will see progress

You should never have to chase a vendor for news. Agree the rhythm before work starts:

A demo of working software every week or two — on a real environment, not slides or screenshots.
A short written update every week: what was done, what is next, the risks, and budget spent against plan.
One named point of contact who replies within an agreed time, and an escalation path up to a director.
Shared tools. You should be able to see the backlog, the code and a test environment at any time.

If you have not seen working software three or four weeks into a build, ask why. Early demos are the best early warning you will get.

Check quality practices, not promises

Every company says it writes quality code, so ask to see how. A team with good habits can show you a redacted pull request, a pipeline run and a test report.

Code review. Every change is reviewed by another engineer through a pull request before it is merged.
Automated tests. Unit tests for business rules, and end-to-end tests for the journeys that make or lose money, such as checkout.
Continuous integration. Every change is built and tested automatically, and a failing build is fixed before new work starts.
Separate environments. Development, staging and production, with realistic but safe test data in staging.
A release and rollback plan. Who deploys, how, and how quickly you can go back if something breaks.
Support after launch. A warranty period for defects, then a support agreement with response times by priority.

If a vendor has no dedicated testers, you can add an independent QA and testing team that reports to you rather than to the developers.

Check references properly

Testimonials on a website are marketing. Ask for two or three clients whose projects look like yours — ideally one that has finished and one that hit problems — and call them.

What did they build for you, and how long did it take against the plan?
Did the team change during the project, and how was the handover?
What happened when something went wrong, or when you disagreed?
Were invoices and change requests predictable?
Would you hire them again for the same kind of work?

Then do your own checks. Look up the company’s registration and status on the Ministry of Corporate Affairs portal, verify its GSTIN on the GST portal, compare the headcount it claims with LinkedIn, and ask to meet the team.

Red flags

Slow down, or walk away, if you see any of these:

A price far below every other quote, with no clear reason.
A fixed price for a complex product after a single call.
No named team, or no chance to speak to the engineers.
Code kept on the vendor’s account until the final payment.
Pressure to sign this week to get a discount.
References that are all years old, or only available as written quotes.
A contract with no exit, handover or IP assignment clause.

Questions to ask on the first call

Ask every company the same ten questions and write the answers down, so you can compare them side by side.

What have you built that is like this?Two recent examples, and clients you can call.
Who would work on our project?Names, seniority and current workload.
How does discovery work, and what do we get at the end?A written scope, a prototype and an estimate you could take elsewhere.
Which engagement model would you suggest, and why?A good answer depends on how settled your scope is.
Where will the code live, and when do the rights pass to us?Your repositories from day one, and a written assignment.
How do you test, review and release?Listen for code review, automated tests and a rollback plan.
How will we see progress?Working software every week or two, plus a written update.
What happens if someone leaves, or if we want to stop?Replacement, overlap and a handover clause.
How will you handle our customers’ personal data?Access control, masked test data and fast incident reporting.
What do you need from us?A good vendor asks for a decision-maker’s time every week. If they need nothing from you, be wary.

If you would like a second opinion on a proposal, or a quote to compare it with, book a call with us. If your company is outside India, how we work with clients abroad covers the hours, invoices and data rules, and our custom software development page shows the engineering standards we work to.

Common questions

How do I choose a software development company in India?

Write a one-page brief, shortlist three or four companies with similar past work, and ask each for a paid discovery or a detailed estimate on the same scope. Then compare the named team, the engagement model, how they test and release, who owns the code and what their references say.

Is fixed price or time and materials better for outsourcing software?

Fixed price suits small, clear scopes that will not change. Time and materials suits products that will change as you learn from users, as long as someone on your side sets priorities every week. A common approach is fixed price for discovery and the first release, then time and materials or a dedicated team.

Who owns the source code when you outsource software development in India?

Under the Copyright Act, 1957, code written by the vendor’s employees usually belongs to the vendor unless it assigns the rights to you in writing. The assignment should say it is worldwide and for the full term of copyright; if it is silent, the law treats it as lasting five years and covering India only.

How can I check that a software company in India is genuine?

Look up its registration and status on the Ministry of Corporate Affairs portal, verify its GSTIN on the GST portal, speak to two or three past clients, and ask to meet the people who would work on your project.

How much does it cost to hire a software development company in India?

It depends on scope, seniority, technology and engagement model, so compare quotes against the same written scope. Ask each vendor for the team, the hours behind the estimate and what is excluded, such as GST, licences, hosting and support.

Sources

First published 5 October 2026. Spotted something out of date or unclear? Email info@effred.com and we will look at it.