Choosing a software development partner is one of the highest-stakes decisions a company makes. Get it right, and you gain a team that accelerates your product. Get it wrong, and you lose 6-12 months of budget and momentum — we've helped clients recover from both scenarios.
This checklist isn't theoretical. Every item comes from real evaluation failures we've witnessed or been asked to fix. The company with the best website isn't always the best partner. The cheapest bid almost never delivers the best value. And "we use agile" on a pitch deck means absolutely nothing.
Technical Capability (15 Points)
| # | Checkpoint | How to Verify |
|---|---|---|
| 1 | Relevant technology stack experience (not just "we can learn it") | Ask for 3 projects using your specific stack. Review code samples. |
| 2 | Developers have public profiles (GitHub, StackOverflow, blog posts) | Ask for GitHub links. Check commit history — quantity AND quality. |
| 3 | They can articulate architecture decisions, not just follow requirements | Give a system design problem in the technical interview. Listen for tradeoff thinking. |
| 4 | Automated testing is part of their standard process (not optional) | Ask: "What's your typical test coverage on a project?" and "Show me a test suite." |
| 5 | CI/CD pipeline exists and is used for every project | Ask for a demo of their deployment process. If it's manual FTP, walk away. |
| 6 | Code review is mandatory, not optional | Ask: "Who reviews PRs? What's your review turnaround time?" |
| 7 | They use version control properly (feature branches, not committing to main) | Ask for a screenshot of a recent project's branch strategy. |
| 8 | Team includes seniors, not just juniors managed by one senior | Ask for the team composition. If it's 1 senior + 7 juniors, expect problems. |
| 9 | They ask technical questions during the sales process (about your architecture, data, constraints) | A company that doesn't ask questions is planning to wing it. |
| 10 | Technical leadership is accessible, not just account managers | Insist on meeting the actual tech lead who'll work on your project. |
| 11 | They have experience with your scale (10K users vs 10M users) | Ask about load testing, database optimization, and scaling challenges they've solved. |
| 12 | Documentation is part of their deliverable (not an afterthought) | Ask for a sample of architecture documentation from a past project. |
| 13 | They understand your domain (fintech, healthtech, etc.) or are honest about gaps | "We've never built a HIPAA-compliant app but here's how we'd approach it" is better than "sure, we've done healthcare" with no evidence. |
| 14 | Performance and security aren't afterthoughts | Ask: "How do you handle SQL injection prevention?" and "What's your approach to performance testing?" |
| 15 | They can discuss technical tradeoffs honestly, not just agree with everything | Propose a deliberately bad architectural decision and see if they push back. |
Portfolio and References (10 Points)
| # | Checkpoint | How to Verify |
|---|---|---|
| 16 | Portfolio projects are live and functioning (not just screenshots) | Visit the URLs. Test the product. Check load times. |
| 17 | They can provide 3+ client references you can actually call | Call them. Ask: "Would you hire them again? What went wrong?" |
| 18 | Case studies include specific metrics, not just vague descriptions | "Reduced page load time from 4.2s to 1.1s" vs. "improved performance" — insist on specifics. |
| 19 | Client retention rate is high (long-term relationships, not one-offs) | Ask: "What percentage of your clients have been with you over 12 months?" |
| 20 | They've worked with companies your size (startup vs enterprise) | A company that only serves enterprises may over-engineer for a startup, and vice versa. |
| 21 | Clutch/GoodFirms reviews exist and are recent (not all from 2020) | Check for review patterns. All 5-star reviews with identical phrasing = suspicious. |
| 22 | They can explain what they built vs. what was pre-existing | "We built the mobile app; the backend was existing" is honest. "We built everything" when they clearly didn't = red flag. |
| 23 | Failed projects or challenges are discussed openly | A company that claims 100% success rate on every project is lying or cherry-picking. |
| 24 | Team size matches the work they claim | A 10-person company claiming to have built 50 enterprise apps simultaneously? Do the math. |
| 25 | Their own website/product is well-built | If their website is slow, broken, or looks like 2015, what will your product look like? |
Communication and Process (10 Points)
| # | Checkpoint | How to Verify |
|---|---|---|
| 26 | Response time during sales is fast (<24 hours) | If they're slow to respond when they're trying to win your business, imagine post-contract. |
| 27 | They have a defined project methodology (Scrum, Kanban, etc.) | Ask for their sprint template, daily standup format, and how they handle scope changes. |
| 28 | Developers speak directly to you, not only through a PM filter | Request a technical call with the actual developers. If denied, they're hiding something. |
| 29 | They use async communication tools effectively | Ask: "How do you handle questions when there's no timezone overlap?" Loom videos, detailed Slack threads, and documented decisions = good. |
| 30 | Regular progress reporting is standard (not something you have to chase) | Ask for a sample weekly progress report from an existing project. |
| 31 | Escalation paths exist for blockers and disagreements | Ask: "If I have an issue with a developer's performance, what's the process?" |
| 32 | They push back on unrealistic timelines (not just say yes to everything) | A company that agrees to every deadline without questions is planning to cut corners or miss them. |
| 33 | Knowledge transfer is built into the engagement (not charged extra at the end) | Ask: "If we transition off your team, what does the handoff include?" |
| 34 | Timezone overlap is addressed with a concrete plan | "We'll figure it out" is not a plan. 4-hour daily overlap with specific meeting times = a plan. |
| 35 | English fluency among technical staff is verified (not just the PM) | The salesperson's English is always perfect. Insist on live conversation with the developers who'll work on your project. |
Security and IP Protection (8 Points)
| # | Checkpoint | How to Verify |
|---|---|---|
| 36 | NDA is standard, not something they resist | Send your NDA before sharing project details. Any pushback = walk away. |
| 37 | IP assignment clause explicitly transfers all code ownership to you | Review their standard contract. "Work for hire" must be explicit — don't assume it. |
| 38 | Source code is in YOUR repository, not theirs | Code should be committed to your GitHub/GitLab from day one. Not "delivered at the end." |
| 39 | They have data security practices (encryption, access control) | Ask about their laptop policies, VPN usage, and how they handle client data access. |
| 40 | Background checks are performed on developers | Ask: "Do you run background checks? What do they cover?" |
| 41 | SOC 2 or ISO 27001 certification (or working toward it) | For enterprise projects. Smaller companies should at least have documented security policies. |
| 42 | Developer access is provisioned and deprovisioned promptly | Ask: "When a developer leaves, how quickly is their access revoked?" Correct answer: same day. |
| 43 | They don't reuse your code in other projects | Explicit non-reuse clause in the contract. Some vendors build "frameworks" from client code. |
Commercial Terms (7 Points)
| # | Checkpoint | How to Verify |
|---|---|---|
| 44 | Pricing is transparent (no hidden fees) | Get an all-inclusive quote. Ask explicitly about overtime, tool costs, management fees. |
| 45 | Contract has a reasonable termination clause (30-60 days notice) | 6-month lock-in with no exit? That's not confidence — it's a trap. |
| 46 | Payment terms are reasonable (monthly billing, not 100% upfront) | 20-30% upfront for fixed-price projects is standard. 100% upfront = high risk. |
| 47 | Warranty period exists for fixed-price deliverables | 30-90 day warranty for bug fixes post-delivery is standard. No warranty = no accountability. |
| 48 | Replacement guarantee for augmented developers | If a developer doesn't work out within 30 days, they should replace them at no additional cost. |
| 49 | Rates are market-appropriate (not suspiciously low or inflated) | Compare against 3-4 vendors. If one is 50% cheaper than all others, ask why. |
| 50 | The proposal addresses YOUR problem, not their standard template | A proposal that references your specific requirements, challenges, and goals = they listened. A generic 40-page PDF = they copy-pasted. |
Red Flags That Should Kill the Deal
- "We can build anything." Every technology, every industry, every scale. Companies that claim unlimited capability have unlimited mediocrity.
- They won't let you talk to developers. If the sales team insists on mediating all technical conversations, they're protecting you from discovering the team's actual capability.
- No questions during the discovery phase. A partner who accepts your requirements without questions doesn't understand them.
- Pressure to sign quickly. "This rate is only available this week" is a used-car sales tactic, not a professional engagement.
- They badmouth competitors. Professional companies compete on their strengths, not others' weaknesses.
- The team on the proposal differs from the team on the project. "Bait and switch" is the #1 complaint in IT outsourcing. Get named developers in the contract.
The ultimate test: Do a paid pilot project before committing to a long-term engagement. 2-4 weeks, a small but real deliverable, with the actual team that'll work on your project. It costs $5-15K and tells you more about the partnership than any amount of due diligence documents.
Frequently Asked Questions
How many companies should we evaluate before deciding?
Shortlist 4-6, deep-evaluate 3. More than 6 creates decision fatigue and slows the process. Less than 3 doesn't give you enough comparison data. The sweet spot is 3 companies through the full evaluation, including paid pilot projects with 2 finalists.
Should we always choose the company that scores highest on this checklist?
Not necessarily. Weight the categories based on YOUR priorities. If security is critical (healthcare, fintech), weight the security section 2x. If you have strong internal technical leadership, the technical capability section matters less. The checklist is a framework, not a formula.
Is company size a reliable indicator of quality?
No. We've seen 15-person boutique firms deliver better work than 500-person companies. Large firms have more resources but also more bureaucracy, higher overhead (you're paying for it), and more likely to assign junior developers. For projects under $200K, mid-size firms (20-100 people) often provide the best balance.
What if a company scores well but their rates are the highest?
Consider total cost of ownership, not hourly rate. A $45/hour team that delivers in 3 months costs less than a $25/hour team that takes 8 months, misses requirements, and needs rework. We've seen the "cheap" option cost 2-3x more than the "expensive" one when accounting for delays, defects, and management overhead.