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.
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?