Software Vendor Selection Checklist for Indian Firms

Most failed software projects in Indian companies do not fail at go-live. They fail months earlier, at the point where a vendor was chosen on a slick demo and a low quote. A structured software vendor selection checklist is the simplest way to stop that from happening, because it forces the buying team to compare vendors on the same terms and to write down what "good" looks like before anyone sees a presentation.

The problem is rarely a lack of options. A Mumbai manufacturer, a Pune logistics firm or a Maharashtra government department can easily collect ten proposals for an ERP, a portal or a mobile app. What they lack is a fair way to separate a capable partner from one that simply writes good proposals. This guide gives you that method, step by step.

Step 1: Define the Problem Before You Meet Any Vendor

Vendors will shape your requirements if you let them. Each one will describe your problem in a way that fits their product. Start instead with an internal document that answers a few plain questions:

• What business problem are we solving, and how do we measure success in six and twelve months?
• Who are the users, how many are there, and where do they work (office, field, branches, citizens)?
• Which existing systems must the new software talk to, such as Tally, an HRMS, a payment gateway or a government API?
• What is fixed (budget ceiling, go-live date, hosting location) and what is flexible?
• Who inside the organisation owns the decision, and who signs off on acceptance?

If this document is hard to write, that is a signal. It often helps to bring in an independent adviser at this stage. Our enterprise advisory services are built for exactly this kind of requirement framing, before any vendor is involved.

Step 2: Build a Weighted Software Vendor Selection Checklist

A checklist without weights treats a minor feature and a security gap as equal. Agree on weights with your stakeholders first, then score every vendor against the same criteria. A typical split looks like this, though you should adjust it to your context:

1. Functional fit (25 to 30 percent): how well the solution meets must-have requirements without heavy customisation.
2. Technical quality (15 to 20 percent): architecture, scalability, integration approach, code ownership and documentation.
3. Delivery capability (15 to 20 percent): team strength, project management method, similar past work you can verify.
4. Security and compliance (10 to 15 percent): secure development practices, access control, data handling and audit support.
5. Support and maintenance (10 percent): SLAs, escalation paths, local presence and response hours.
6. Total cost of ownership (15 to 20 percent): licences, implementation, hosting, AMC and change requests over three to five years.

Have at least three people score independently, then compare. Large gaps between scorers usually reveal unclear requirements rather than a weak vendor.

Must-haves versus nice-to-haves

Mark a small number of criteria as pass or fail. If a vendor cannot host data in India when you need it, or cannot integrate with your core system, no score on other criteria should rescue them.

Step 3: Check Technical Depth, Not Just the Demo

Demos show the best path through the software. Your users will not stay on that path. Ask each shortlisted vendor to run a scripted demo using your scenarios and, where possible, your sample data. Then go deeper:

• Ask for an architecture diagram and explain how the system handles growth in users and data.
• Ask how integrations are built: standard APIs, file transfers or custom scripts.
• Ask who owns the source code for custom work, and whether you receive it along with documentation.
• Ask about their testing approach: unit tests, user acceptance testing support and performance testing.
• Ask how releases and updates are deployed, and how much downtime they cause.

For custom builds, it helps to understand what good engineering looks like. Our product engineering team follows the same questions internally, and you should expect any serious vendor to answer them clearly.

Step 4: Assess Security, Data Protection and Compliance

Security questions are often left to the end and answered with a brochure. Treat them as part of the core evaluation instead. Useful questions include:

• How is user access controlled, and does the system support role-based permissions and audit logs?
• Where will data be stored and backed up, and can it stay within India if required?
• Has the application been through independent security testing, and will they fix findings at no extra cost?
• How will they handle personal data of employees, customers or citizens?

India passed the Digital Personal Data Protection Act in 2023, and the detailed rules are still awaited. Even so, it is sensible to ask vendors how their product supports consent records, data minimisation and deletion requests, so that you are not forced into rework later. For government buyers, confirm whether the solution needs to meet accessibility and website guidelines applicable to your department.

Step 5: Verify References and Delivery Track Record

Every vendor has happy clients. The value of reference checks comes from asking the right questions. Speak to at least two references per vendor, ideally of a similar size and sector to yours, and ask:

• Did the project finish on time and near the original budget? If not, why?
• How did the vendor handle scope changes and disagreements?
• Is the same team still supporting you, or has it changed?
• How quickly are support tickets resolved in practice?
• Would you choose them again?

Also check basic business health: years of operation, GST registration, the size of the delivery team and whether key people named in the proposal will actually work on your project.

Step 6: Compare Commercials and Contract Terms

The lowest quote is often the most expensive over five years. Break every proposal into the same cost lines so you are comparing like with like: one-time implementation, licences or subscriptions, hosting, training, annual maintenance and the rate card for change requests.

Then review the contract carefully before you sign:

• Scope and acceptance: a clear statement of deliverables and how acceptance is tested.
• Payment milestones: linked to working deliverables, not calendar dates.
• SLAs and penalties: response and resolution times with defined severity levels.
• Intellectual property: ownership of custom code, data and configurations.
• Exit clause: data export format, handover support and transition timelines if you part ways.

An exit clause feels negative at the start of a partnership. It is also the clause you will be most grateful for if things go wrong.

Frequently Asked Questions

How many vendors should we shortlist?

Three to four is usually right. Fewer limits your comparison; more makes detailed evaluation and reference checks impractical for a small internal team.

Should we choose a product or a custom build?

Choose a product when your processes are fairly standard and the product fits most requirements out of the box. Choose a custom build when your process is a real differentiator or no product fits without heavy changes.

How long should vendor selection take?

For a mid-sized project, four to eight weeks is common: two weeks for requirements, two to three weeks for proposals and demos, and one to two weeks for references and negotiation.

What is the biggest mistake in vendor selection?

Deciding on price and demo alone. Without weighted criteria, reference checks and a clear contract, a cheap vendor can become the costliest choice.

How Affix Center Can Help

Affix Center works with enterprises, SMEs and government departments across Mumbai and Maharashtra on requirement definition, vendor evaluation and contract review. We can help you build your software vendor selection checklist, run structured demos and compare proposals on a fair basis, whether or not we are one of the bidders being considered.

If you are planning a software purchase and want a second opinion before you commit, talk to our advisory team.