Software Vendor Evaluation Checklist: 50 Questions to Ask
Author
ZTABS Team
Date Published
Choosing a software vendor is a high-stakes decision that shapes your project's outcome before a single line of code is written. Yet many companies approach vendor selection casually — relying on a polished sales pitch, a slick portfolio, or the lowest bid to make their choice.
The companies that consistently get great results from external vendors use a structured evaluation process. They ask the same questions of every candidate, score responses objectively, and make decisions based on evidence rather than impressions.
This checklist provides the 50 questions you should ask — organized by category — along with what good answers look like and red flags to watch for.
Company and Stability (Questions 1-10)
These questions assess whether the vendor is a stable, reliable partner.
1. How long has your company been in business? Good: 5+ years with consistent growth. Red flag: Brand new company or frequent rebranding.
2. How many employees do you have, and what is the ratio of developers to non-developers? Good: At least 60% technical staff. Red flag: More salespeople than developers.
3. What is your annual revenue range? Good: Revenue appropriate for your project size (do not be their biggest client by 10x). Red flag: Evasive answers or dramatic fluctuations.
4. What is your employee retention rate? Good: Above 85% annual retention. Red flag: Below 70%, or unwillingness to answer.
5. Can you share three client references for projects similar to ours? Good: Readily provides references with contact details. Red flag: Only offers testimonials without contact information.
6. What industries do you specialize in? Good: Clear focus areas with demonstrated depth. Red flag: "We do everything for everyone."
7. What are the credentials and backgrounds of your leadership team? Good: Technical leadership with hands-on experience. Red flag: Leadership is entirely sales-focused.
8. Do you have any pending litigation or unresolved disputes with clients? Good: Transparent answer. Red flag: Evasive or defensive response.
9. What professional certifications or partnerships do you hold? Good: Relevant certifications (AWS, Azure, ISO 27001, SOC 2). Red flag: No verifiable credentials.
10. How do you handle intellectual property ownership? Good: Client owns all IP by default. Red flag: Vendor retains IP rights or licenses back to you.
Technical Competence (Questions 11-25)
These questions reveal whether the vendor can actually deliver what they promise.
11. What technology stacks do you specialize in? Good: Focused expertise in relevant technologies. Red flag: Claims expertise in everything.
12. Walk me through the architecture of a recent project similar to ours. Good: Detailed, thoughtful explanation with rationale for decisions. Red flag: Vague answers or inability to explain technical choices.
13. How do you approach technology selection for a new project? Good: Client needs and requirements drive the choice. Red flag: "We use [technology X] for everything."
14. What is your approach to automated testing? Good: Testing integrated into development process, clear coverage targets. Red flag: "We test at the end" or no mention of automated tests.
15. What does your code review process look like? Good: Every pull request reviewed by at least one other developer. Red flag: No code review process.
16. How do you handle security in your development process? Good: Security reviews, dependency scanning, OWASP compliance, penetration testing. Red flag: "We handle security at the end."
17. What CI/CD tools and practices do you use? Good: Automated build, test, and deployment pipelines. Red flag: Manual deployments.
18. How do you manage technical debt? Good: Proactive approach with allocated time for debt reduction. Red flag: "What is technical debt?" or no awareness.
19. Can you show us a code sample from a previous project? Good: Willingly shares anonymized examples. Red flag: Refuses to show any code.
20. How do you handle database design and data migrations? Good: Structured approach with versioned migrations and rollback plans. Red flag: Ad-hoc database changes.
21. What is your approach to API design? Good: RESTful or GraphQL standards, versioning, documentation. Red flag: No API design standards.
22. How do you handle performance optimization? Good: Proactive monitoring, load testing, performance budgets. Red flag: "We optimize when there are complaints."
23. What is your DevOps and infrastructure management approach? Good: Infrastructure-as-code, automated provisioning, monitoring. Red flag: Manual server configuration.
24. How do you ensure accessibility compliance? Good: WCAG standards integrated into development and testing. Red flag: No awareness of accessibility requirements.
25. What is your experience with our required compliance standards? Good: Specific examples of delivering compliant systems. Red flag: Claims compliance experience but cannot provide details.
Process and Methodology (Questions 26-35)
These questions assess how the vendor manages projects.
26. What development methodology do you follow? Good: Agile/Scrum with clear sprint cadences and ceremonies. Red flag: Waterfall for custom software, or no defined methodology.
27. How do you handle the discovery and planning phase? Good: Dedicated discovery phase with clear deliverables. Red flag: Jumps straight to development.
28. What project management tools do you use? Good: Industry-standard tools (Jira, Linear, Asana) with client access. Red flag: Email and spreadsheets only.
29. How often will we receive project updates? Good: Weekly demos minimum, daily written updates, real-time project board access. Red flag: Monthly reports only.
30. How do you handle scope changes during a project? Good: Formal change request process with impact assessment. Red flag: "We are flexible" with no defined process.
31. What happens if a project is falling behind schedule? Good: Early warning system, root cause analysis, transparent communication, recovery plan. Red flag: "That does not happen" or evasive answer.
32. How do you handle disagreements with clients? Good: Escalation process, data-driven discussions, willingness to have difficult conversations. Red flag: Pure agreeability (they tell you what you want to hear).
33. What does your QA process look like? Good: Dedicated QA resources, defined test plans, multiple testing types. Red flag: Developers test their own code only.
34. How do you handle post-launch support? Good: Defined warranty period, support SLAs, ongoing maintenance options. Red flag: No post-launch support included.
35. Can you describe your deployment process? Good: Automated, repeatable, with rollback capability. Red flag: Manual, ad-hoc deployments.
Team and Communication (Questions 36-45)
These questions assess the people who will actually work on your project.
36. Who specifically would work on our project? Good: Named individuals with relevant backgrounds. Red flag: "We will assign the right team" without specifics.
37. Can we interview the proposed developers? Good: Yes, they encourage it. Red flag: Access only through account managers.
38. What is the seniority mix of the proposed team? Good: Senior-led with a clear breakdown. Red flag: All junior developers or unspecified seniority.
39. What happens if a key team member leaves during the project? Good: Knowledge sharing practices, documentation standards, replacement plans. Red flag: No contingency plan.
40. Will we have a dedicated project manager? Good: Yes, with defined responsibilities and availability. Red flag: Project management is shared across many clients.
41. What communication channels do you use? Good: Slack/Teams for daily communication, video for meetings, shared documentation. Red flag: Email only.
42. What time zone does your team operate in? Good: Significant overlap with your business hours (4+ hours). Red flag: Zero overlap with no communication plan.
43. How do you onboard new team members mid-project? Good: Documented onboarding process, codebase documentation, pair programming. Red flag: "Throw them in and they figure it out."
44. How do you handle knowledge transfer at project completion? Good: Documented runbooks, architecture guides, training sessions, transition period. Red flag: No knowledge transfer plan.
45. Can you share your team's approach to documentation? Good: Documentation is a deliverable, maintained throughout the project. Red flag: "We document at the end" or "the code is the documentation."
Pricing and Contracts (Questions 46-50)
These questions protect your software investment.
46. What pricing model do you recommend for this project, and why? Good: Recommends the model best suited to your situation with clear rationale. Red flag: Only offers one model regardless of context.
47. What is included in your pricing, and what costs extra? Good: Detailed breakdown with no surprises. Red flag: Vague "it depends" answers.
48. What are your payment terms? Good: Milestone-based payments tied to deliverables. Red flag: 100% upfront or large upfront percentage.
49. What is your warranty policy for delivered work? Good: 30-90 day warranty for bug fixes at no additional cost. Red flag: No warranty period.
50. What are the termination terms? Good: Reasonable notice period (30 days), you receive all work completed to date. Red flag: Long lock-in periods, no termination clause, or penalty fees.
Using the Checklist
Scoring Method
For each question, score the vendor's response:
- 3 points: Strong, detailed answer with evidence
- 2 points: Adequate answer, meets minimum expectations
- 1 point: Weak answer, missing detail, or concerning response
- 0 points: No answer, red flag, or disqualifying response
Weighted Categories
| Category | Weight | Max Score | |---|---|---| | Company and Stability (Q1-10) | 15% | 30 | | Technical Competence (Q11-25) | 30% | 45 | | Process and Methodology (Q26-35) | 20% | 30 | | Team and Communication (Q36-45) | 25% | 30 | | Pricing and Contracts (Q46-50) | 10% | 15 |
Decision Thresholds
- Above 80%: Strong candidate — proceed to reference checks and pilot
- 60-80%: Acceptable candidate — investigate weak areas before proceeding
- Below 60%: Significant concerns — consider alternative vendors
Final Advice
No vendor is perfect. The goal is not to find a vendor with zero weaknesses — it is to find one whose strengths align with your priorities and whose weaknesses you can manage.
The most important thing you can do is meet the actual people who will work on your web development project. Sales teams are paid to impress you. The developers, project managers, and architects who will do the daily work are the ones who determine your project's success.
Looking for a vendor that welcomes this level of scrutiny? Contact our team and ask us any of these 50 questions. We believe that transparency in the evaluation process is the foundation of a successful partnership.
Need Help Building Your Project?
From web apps and mobile apps to AI solutions and SaaS platforms — we ship production software for 300+ clients.
Related Articles
Digital Transformation Roadmap for SMEs: A Practical Guide
Digital transformation does not require enterprise budgets. This step-by-step roadmap shows SMEs how to modernize operations, reduce costs, and compete with larger players through strategic technology adoption.
8 min readThe ROI of Automation for Small Businesses: What the Numbers Say
Automation is not just for enterprises. Small businesses that strategically automate key processes see measurable ROI within months. Here is how to calculate the return and prioritize the right investments.
8 min readHow to Budget for Software Development: A CFO-Friendly Guide
Software budgets are notoriously hard to get right. This guide gives business leaders a realistic framework for planning, allocating, and managing software development spending without surprises.