Software Vendor Selection Checklist for Indian Firms

Quick answer: A software vendor selection checklist is a written, weighted list of criteria that every vendor is scored against on the same terms. It covers functional fit, technical quality, delivery capability, security and compliance, support, and total cost of ownership, plus a few pass or fail must-haves agreed before any demo.

Most failed software projects in Indian companies do not fail at go-live. They fail months earlier, when a vendor was picked on a polished demo and the lowest quote. By the time missing features, weak support or hidden change-request costs appear, the contract is signed and switching is painful.

A structured software vendor selection checklist stops that from happening. It forces the buying team to write down what "good" looks like before anyone sees a presentation, and to compare every vendor on the same basis. This guide gives you the checklist, a scoring template and a step-by-step method that works for ERP, HRMS, portals, mobile apps and custom builds.

Why Vendor Selection Goes Wrong

The problem is rarely a lack of options. A manufacturer, a logistics firm or a government department can easily collect ten proposals. What is missing is a fair way to separate a capable partner from one that simply writes good proposals. The usual mistakes are:

• Requirements written by the vendor. Each vendor describes your problem in a way that fits their product.
• Demo-led decisions. Demos show the best path through the software, not the messy cases your users face.
• No weights. A minor feature and a security gap are treated as equal.
• Price compared on different terms. One quote includes hosting and training, another does not.
• Weak contracts. No acceptance criteria, no exit clause, no clarity on who owns the code.

Each mistake has a matching step in the method below.

The Software Vendor Selection Checklist and Scoring Template

Agree the weights with your stakeholders first, then score each vendor from 1 to 5 on every criterion and multiply by the weight. Adjust the weights to your context; the split below is a sensible starting point.

Criterion	Suggested weight	What to check	Evidence to ask for
Functional fit	25 to 30%	Must-have requirements met without heavy customisation	Scripted demo on your scenarios and sample data
Technical quality	15 to 20%	Architecture, scalability, integrations, code ownership, documentation	Architecture diagram, API documentation, sample handover document
Delivery capability	15 to 20%	Team strength, project method, similar past work	Named team CVs, project plan, verifiable references
Security and compliance	10 to 15%	Access control, audit logs, data location, personal data handling	Security testing summary, data flow description, hosting details
Support and maintenance	10%	SLAs, escalation, response hours, local presence	Draft SLA with severity levels, ticket reports from a live client
Total cost of ownership	15 to 20%	Licences, implementation, hosting, AMC and change requests over 3 to 5 years	Cost sheet in your standard format, rate card for changes

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

How the scoring works in practice

Say functional fit carries a weight of 30 and a vendor scores 4 out of 5. That vendor earns 120 points on that line. Add up the lines for each vendor to get a total out of 500. Keep the score sheets and short written reasons for each score. They help you explain the decision to management or auditors later, and they make debriefing unsuccessful bidders easier and fairer. If two vendors finish within a few points of each other, treat it as a tie and let reference checks and contract terms decide.

Must-haves versus nice-to-haves

Mark a small number of criteria as pass or fail. If a vendor cannot keep data in India when you need it, or cannot integrate with your core system, no score elsewhere should rescue them. Typical pass or fail items are data location, a key integration, a hard go-live date and a budget ceiling.

The Fix: How to Run Vendor Selection in 7 Steps

1. Define the problem before meeting vendors: Write an internal note on the business problem, success measures at six and twelve months, users and locations, systems to integrate, fixed limits and who signs off.
2. Agree weights and must-haves: Fix the criteria, weights and pass or fail items with stakeholders before any proposal is opened.
3. Shortlist three or four vendors: Use a short questionnaire to drop vendors that fail must-haves, so detailed evaluation stays manageable.
4. Run scripted demos on your scenarios: Give every shortlisted vendor the same scenarios and sample data, and score them live against the checklist.
5. Test technical depth and security: Review architecture, integrations, testing, code ownership, access control and data handling with someone technical in the room.
6. Check references the right way: Speak to at least two clients of similar size and sector per vendor, and ask about delays, scope changes, team continuity and support in practice.
7. Compare commercials and contract terms: Put every quote into the same cost lines over three to five years, then review scope, acceptance, payment milestones, SLAs, intellectual property and exit terms before signing.

Testing Technical Depth Beyond the Demo

Your users will not stay on the vendor's happy path. Go deeper with these questions:

• How does the system handle growth in users and data? Ask for an architecture diagram.
• How are integrations built: standard APIs, file transfers or custom scripts?
• Who owns the source code for custom work, and is it handed over with documentation?
• What is the testing approach: unit tests, user acceptance testing support and performance tests?
• How are updates released, and how much downtime do they cause?

For custom builds, our guide on choosing a software development company lists more questions on engineering quality.

Security, Data Protection and Compliance Questions

Security is often left to the end and answered with a brochure. Treat it as part of the core evaluation:

• Does the system support role-based permissions and audit logs?
• Where is data stored and backed up, and can it stay within India if required?
• Has the application been through independent security testing, and will the vendor fix findings at no extra cost?
• How will it support consent, data minimisation and deletion requests for personal data?

India's Digital Personal Data Protection Act, 2023 is now backed by the DPDP Rules, 2025, notified in November 2025 and coming into force in phases. Ask vendors how their product helps you meet these duties; our DPDP Act compliance checklist explains the main ones. Government buyers should also confirm any accessibility and website guidelines that apply to their department, and those buying through GeM can read our guide to procuring IT services on GeM.

Reference Checks That Actually Tell You Something

Every vendor has happy clients. Ask references:

• 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?
• How quickly are support tickets resolved in practice?
• Would you choose them again?

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

Commercials and Contract Terms

The lowest quote is often the most expensive over five years. Break every proposal into the same lines: implementation, licences or subscriptions, hosting, training, annual maintenance and the change-request rate card. Then check the contract for:

• Scope and acceptance: a clear list of deliverables and how acceptance is tested.
• Payment milestones: linked to working deliverables, not calendar dates.
• SLAs and penalties: response and resolution times by severity. Our article on SLA metrics explains which ones matter.
• Intellectual property: ownership of custom code, data and configuration.
• Exit clause: data export format, handover support and transition time.

If you are also deciding whether to build an internal team instead, see IT outsourcing vs in-house team.

Frequently Asked Questions

What should a software vendor selection checklist include?

Functional fit, technical quality, delivery capability, security and compliance, support and maintenance, and total cost of ownership, each with an agreed weight, plus a short list of pass or fail must-haves.

How many vendors should we shortlist?

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

Should we choose a product or a custom build?

Choose a product when your processes are fairly standard and it fits most needs 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: about two weeks for requirements, two to three for proposals and demos, and one to two 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 in Mumbai and across Maharashtra on requirement definition, vendor evaluation and contract review. Our enterprise advisory team can build your weighted checklist, run scripted demos and compare proposals fairly, whether or not we are one of the bidders. Where a custom build is the right answer, our product engineering team can scope it.

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