How to choose a software development company in India

Choose a software development company by verifying the firm on public registers, meeting the people who will build, and fixing code ownership in writing. Work through nine steps: the problem, the firm, proof of similar work, the team, the process, commercial terms, ownership, security duties and life after go-live. Score every firm on one sheet before you read proposals. Buyers skip verification and ownership most often.

1. Write the problem down first

A shortlist is only as good as the brief. Write one page: the process that hurts, the people who use it, the systems it must connect to, and the date by which something must work. Name the decision-maker. Vendors answer a vague brief with a vague quote, and you cannot compare the two.

If you cannot write the page, that is the first job. See why software projects fail in the two months before the code.

2. Verify the firm on public registers

Three Indian registers offer public checks, according to their own portal pages.

Match the legal name across all three and your contract. Ask for the registered address. A firm that gives only a brand name and a mobile number has told you something.

3. Ask for proof from similar work

A portfolio page shows what a firm wants seen. A reference call shows what happened. Ask for:

• two clients with a similar process, size and systems to yours
• permission to call their project owner, not their procurement desk
• the question "what went late, and why?" asked on that call
• the same system still running two years after launch, if the work is that old
• a named person from the client side who accepted the release

Case studies with named systems, dates and results are worth more than logos. A firm that cannot show similar work can still be right for you, but then the pilot below matters more.

4. Meet the people who will build

The people at the sales meeting often differ from the people on the project. Ask:

1. Who will lead delivery, and will I meet them before I sign?
2. Which roles are on the team, and for how many days each?
3. If an engineer leaves, who replaces them, and who pays for the overlap?
4. Are the engineers employees, or subcontractors from another firm?

Write the answers into the contract as named roles. A team you cannot name is a team you cannot hold to account.

5. Test the process

Ask to see how a project runs, with artefacts, not slogans.

• A release rhythm. Working software in a live test environment every one to two weeks, so your users see real screens.
• A written status report on a fixed day, with progress against plan, risks and decisions needed.
• Acceptance criteria written per feature before it is built, so "done" is not an opinion.
• An escalation path with names: delivery lead, then architect, then a director.
• Your own repository, board and build pipeline, with the vendor as a user.

If you can, start with a paid pilot of one module or one fortnight. A pilot costs little against a failed project.

6. Compare commercial terms, not only the total

Two quotes with the same total can carry very different risk. Compare:

For how to read a quote, see what drives the cost of custom software in India.

7. Fix code ownership in writing

Code ownership is the clause that Indian buyers most often assume and rarely check.

Under section 19 of the Copyright Act, 1957, an assignment of copyright is valid only if it is in writing and signed by the assignor. If the contract does not state the period, the assignment is deemed to last five years from the date of assignment. If it does not state the territory, it is presumed to extend within India only.

In 2011 a Division Bench of the Delhi High Court applied these defaults to software. In the judgment in Pine Labs v Gemalto, the master services agreement assigned the IP without stating a duration or territory. The court held that sections 19(5) and 19(6) were triggered whatever the nature of the agreement, and it set aside the single judge's order. The findings were made at the interim stage, so read the judgment, not this summary, before you rely on it.

So write the clause out. It should say who owns the code, for how long (without limit, if that is the intent), for which territory (worldwide), and that third-party and open-source components carry their own licences, listed in a schedule. Better still, ask that the code lives in your own repository from the first commit, so the question of delivery never arises. See also who owns the ERP after go-live.

8. Check security and data duties

Your company carries the legal duty even when a vendor holds the data. Two Indian rules matter in a vendor contract, as described by CERT-In and PIB:

• CERT-In directions of 28 April 2022: according to CERT-In, listed incidents must be reported cyber incidents within six hours and ICT logs kept for a rolling 180 days within India. Ask who will report, and whether the vendor's systems keep those logs. CERT-In directions.
• DPDP Rules, 2025: if the vendor sees personal data, name it in the contract, limit its access, and list its sub-processors. According to PIB, failing to notify a breach can attract one of the larger penalties in the Act's Schedule. PIB on the DPDP Rules.

Ask for certificates with their scope and the issuing body, such as an ISO/IEC 27001 certificate, and read what the scope covers. For more, see security and IP when engineering happens offshore.

9. Agree what happens after go-live

Most vendor risk sits after launch. Put these in the contract:

• a warranty period, with defects fixed against agreed acceptance criteria
• a support schedule with severities and response times
• documents handed over: architecture notes, runbooks, a data dictionary
• the right to move support to another firm at standard rates, with a handover period
• access to every environment and credential in your name

A scorecard you agree first

Agree the rows and the weights with your team before you read a single proposal. Score each firm 0, 1 or 2 per row, then discuss the gaps.

Warning signs

• The price arrives before anyone has asked about your process.
• The firm will not name who works on the project.
• The contract says nothing about duration or territory of the IP.
• References are available only through the vendor's own sales team.
• The firm wants calendar billing with no deliverable attached.

Public sector buyers

Public bodies buy through tenders, the Government e-Marketplace (GeM) and empanelment. Each adds eligibility rules on turnover, past experience and registration, so check them against a firm's documents before you invest time in a proposal. The ownership, security and exit steps above apply in full. For the procurement rules, see building software for GeM and GFR procurement.

Where Brihat Infotech fits

On Brihat Infotech projects, the source code sits in the client's own repository from the first commit; see how we work.

Start a conversation