Resources · Playbooks

Vendor Selection Playbook 

How to shortlist, interview, and pressure-test a software vendor before you sign: evidence-first questions on delivery process, named engineers, IP ownership, and exit terms that separate a real partner from a well-produced sales deck.

6 min read
Vendor SelectionProcurementDue Diligence

A vendor's website and sales deck are optimized to make every engagement sound identical: agile, transparent, senior engineers, full ownership. The differences that actually matter show up in how a vendor answers specific, uncomfortable questions, not in how polished their case studies are. This is the shortlist-to-signature sequence we'd suggest running with any vendor, including us.

1. Build a Shortlist on Fit, Not Just Reputation

  • Prioritize vendors with direct experience in your industry's compliance and workflow requirements over general-purpose agencies.
  • Check whether their team composition matches your project: an ERP rollout and a greenfield mobile app need different skill mixes.
  • Confirm real timezone overlap for daily standups, not just a claim of round-the-clock availability.
  • Look for evidence of long-term client relationships, not just a portfolio of one-off launches.

2. Ask the Questions That Reveal How They Actually Work

  • Walk me through what happens when a sprint reveals the original scope was wrong. Evasive answers here are a red flag.
  • Who specifically will be on our project, and can we meet them before signing? Named senior engineers, not a generic bios page.
  • What does your code review and testing process actually look like? Ask for specifics, not the word 'agile.'
  • What happens to our code and infrastructure access if we end the engagement early? The answer should be immediate and unambiguous.

3. Pressure-Test Ownership and Exit Terms

Full IP ownership sounds like a standard clause until an engagement ends badly and a client discovers their 'own' code was never actually deployed to infrastructure they control. Before signing, confirm in writing that your repos, your cloud accounts, and your CI/CD pipelines are provisioned under your organization's ownership from day one, not the vendor's, with access merely granted to you. Ask what happens on day one of a dispute: can you rotate credentials, pull the repo, and walk away with a working system? If the honest answer is no, the ownership clause is decorative.

4. Run a Trial Sprint Before Committing Long-Term

The single best filter for vendor selection is a trial period: a short, paid engagement, ideally a discovery phase or one real sprint, before committing to a multi-month contract. A trial reveals communication cadence, code quality, and how the vendor handles a genuine surprise, none of which show up reliably in a sales process. Any vendor confident in their own delivery should welcome a trial; reluctance to start small is itself a data point worth weighing heavily.

5. Check References the Right Way

  • Ask for a reference from a project similar in size and complexity to yours, not just their best-ever engagement.
  • Ask the reference specifically what went wrong during the project and how it was handled, not just whether they'd recommend the vendor.
  • Ask how communication actually happened week to week, such as standups, shared sprint boards, or async updates, and whether that cadence matched what was promised.
  • Ask whether the reference client owns their code and infrastructure outright today, post-engagement.

Want a second opinion on how this applies to your project?