Three mistakes that account for most bad hires
After roughly a decade of being on both sides of the tech vendor table (sometimes as the vendor, sometimes advising the buyer), three mistakes account for most of the bad hires we see. None of them are sophisticated. All of them are avoidable with a checklist and the willingness to actually use it.
Skipping the reference check. The buyer reads the website, watches the demo, gets through two pitch meetings, and signs without ever calling someone the vendor has actually worked with. Reference calls feel awkward to request and feel slow to schedule. They also surface more useful information than any RFP scoring matrix in the same amount of time. Every bad-vendor story we have heard could have been prevented by 30 minutes of reference calling.
Trusting the portfolio at face value. Case studies on vendor websites are marketing materials. They are often genuine, but they are also sometimes embellished or fabricated outright. A five-minute verification routine (described below) catches the worst of it. Most buyers do not run it.
Signing the contract without reading the IP clause. The most expensive line in most software development contracts is the one about who owns the work. Defaults are not your friend. If the IP clause is not specifically structured so you own what is built for you, you do not own it.
Three mistakes account for most bad vendor hires: skipping references, trusting portfolios, and signing without reading the IP clause. A 12-point checklist filters most of the rest. Review platforms (GoodFirms, G2, Trustpilot) are useful filters, not verdicts. Seven specific reference-call questions catch more than any RFP scoring matrix. The expensive red flags are in the contract: scope-creep language, IP carve-outs, sub-contracting without disclosure.
The 12-point due diligence checklist
This is the checklist we run on every vendor we recommend, and the one we ask clients to run on us. None of the points are exotic. The discipline is just running through all twelve every time.
Run through every point before signing anything
- 1. Company registration and ownership. Confirm the legal entity exists, when it was registered, and who the listed directors are. Most jurisdictions publish this on a government registry.
- 2. Team size and tenure. Ask how many people work full-time, how long the senior people have been with the company, and how many will work on your project. Cross-reference against LinkedIn.
- 3. Active clients and tenure. Ask for two current and two former clients. The shape of the answer (specific names vs. evasiveness) is itself a signal.
- 4. Portfolio verification. Pick three case studies and verify them (see next section).
- 5. Reference calls. Schedule at least two 30-minute reference calls with clients you did not pick, not the ones the vendor selected.
- 6. Technical practices. Ask about their code review process, testing approach, CI/CD setup, and how they handle on-call.
- 7. Security posture. Ask about access management, secrets handling, incident response, and any compliance certifications (SOC 2, ISO 27001) they actually maintain.
- 8. Sub-contracting policy. Ask if any work will be outsourced and to whom. Confirm in writing.
- 9. IP and ownership terms. Read the proposed contract IP clause. Make sure work-product ownership transfers to you on payment.
- 10. Contract change and exit terms. Confirm a written exit clause (typically 30 days notice), scope-change procedure, and the cost of ending the engagement early.
- 11. Pricing structure transparency. Ask how invoices will be itemised, how change orders are priced, and what the rate is for additional people if the team scales.
- 12. Communication cadence. Confirm meeting frequency, response-time commitments, and the named individuals you will work with day-to-day.
Twelve points is not exhaustive. It is the floor. A vendor who has thought seriously about their own practice can answer all twelve in a 90-minute meeting without hedging.
Where do review platforms like G2 and GoodFirms actually help vet a tech vendor?
share of B2B buyers using online reviews to inform purchasing decisions; 90%+ of those readers share findings with at least one buying-committee member, per the G2 2025 Buyer Behaviour Report.
global buyers reached by G2 and 3M+ reviews across 200,000+ products in 2025, per G2 2025 Year in Review.
share of B2B service contracts that fail; enterprises lose ~9% of revenue to contract value leakage from vague terms and weak enforcement, per Sirion contract intelligence research.
Review platforms like GoodFirms, G2, Trustpilot, and similar aggregators are useful at a specific job: building an initial filtered list of vendors that look credible at the surface. They are not useful as a final ranking, and most buyers conflate the two.
Each platform has its own bias. GoodFirms verifies reviews through interviews and is stronger on software-services vendors. G2 is stronger on B2B SaaS products with self-serve user bases. Trustpilot is consumer-skewed and has less stringent review-verification, which makes it useful for some categories and noisy for others. None of them solve the underlying problem of “is this vendor good for our specific situation.”
Start a vendor search on two of these platforms to get a credible shortlist of 8 to 12. Filter to four to six based on geographic fit, technology focus, and team size. Then run the 12-point checklist on each one. The review-platform score itself should not be in the final decision.
How can you spot a fabricated portfolio case study before signing?
Most portfolio verification takes about five minutes per case study. We have a routine.
-
Check whether the client company exists and is operating
Search the company name on LinkedIn and on a government business registry. Real clients have real LinkedIn presences. Fabricated ones often do not, or have one that was created the same month as the case study.
-
Cross-reference the named contact
If the case study quotes a named individual at the client, find them on LinkedIn. Confirm they actually work there and held that role at the time the project happened. Fabricated case studies often use plausible-sounding names that do not match real people.
-
Examine the project specifics
Real case studies tend to include awkward, specific details (a particular technology choice, a specific bug, a specific compromise made for budget). Fabricated ones tend to be smooth and generic. The presence of friction in the narrative is a credibility signal.
-
Ask for a metric you can verify
If the case study claims “increased conversion 47%,” ask for the methodology and the comparison window. Real metrics have honest caveats. Fabricated ones are usually round numbers in a way that real measurements rarely are.
-
Ask to speak with the named client
The vendor will sometimes refuse for reasonable reasons (the client cannot be a public reference). Sometimes they will refuse because the client does not exist. Pay attention to which.
The reference-call playbook (7 questions)
A 30-minute reference call done well filters more bad vendors than any other single artefact in the due diligence process. The questions matter. Asking “were they good?” produces “yes, they were good.” The seven questions below produce information that is actually useful.
Run these in order, in a 30-minute conversation
- 1. What was the engagement scope and timeline? Confirms the case study matches reality.
- 2. What did they do well? Lets the reference start positive. Pay attention to whether the answer is specific or generic.
- 3. What did they do badly? Every vendor has weaknesses. A reference who cannot name any is either a fabricated reference or a client who has not worked with them seriously.
- 4. What was the biggest surprise during the engagement? Surfaces the unspoken issues that do not make the case study.
- 5. Who specifically did the work? Confirms the senior people who pitched are the ones who delivered, not a junior team.
- 6. How did they handle a missed deadline or a scope change? Every project has one. The handling tells you most of what you need to know.
- 7. Would you hire them again, and why or why not? The honest summary. Pay attention to hesitation as much as words.
Which tech vendor contract red flags do 80% of buyers miss?
The expensive part of vendor selection is in the contract. Three red flags account for most of the post-signing surprises.
Scope-creep language: “Vendor reserves the right to bill additional hours at the standard rate for work outside the agreed scope.” Reasonable in principle, weaponised in practice. Specify what counts as outside scope, and require written approval (not Slack) before additional hours are billed. IP carve-outs: “Vendor retains ownership of pre-existing tools and frameworks used in the engagement, including any modifications made during the engagement.” This last clause is the trap. Insist on full ownership transfer of work product, with named exceptions for genuinely pre-existing IP. Sub-contracting without disclosure: The contract should require written notice and approval before any work is outsourced. Without that clause, you may end up paying senior rates for junior offshore labour without realising it.
The same vendor-evaluation discipline applies whether you are buying development services, AI consulting, or any other technical capability. The patterns we cover in SMB consulting models are the seller-side analogue of the buyer-side framing in this article. Both rely on the same observation: the engagement model and the contract matter more than the firm. The strategic frame extends through AI product strategy and the operating model side in continuous digital transformation.
Book a 30-minute vendor-fit screen.
Send us the shortlist and the contract terms. We will read both and write back with a punch list inside 48 hours. Fixed price, no upsell.
Vendor selection is one of those decisions that almost never feels urgent and almost always pays back when treated as if it were. The work of running through the checklist takes a few hours. The cost of skipping it usually runs to a quarter or two of rework. The practice we describe in our consulting page and on the build side in our development page both lean on the same observation: the cheapest mistake to fix is the one you catch before signing.
Frequently asked questions
How long should a full due diligence cycle take?
For a meaningful engagement (six months or longer, or six figures of total cost), plan two to three weeks of due diligence. That includes initial shortlist screening, 12-point checklist on three to five finalists, reference calls, and contract negotiation. Compressed timelines below ten business days almost always skip the reference calls, which is the highest-leverage part.
What if the vendor refuses to provide references?
This is itself a signal. Real reasons exist (client confidentiality, recent ramp where references are not yet mature), but they should be explained specifically. A generic refusal is almost always a sign that something else is going on. If they cannot provide any references at all, do not sign.
How do we handle international vendors?
Run the same 12-point checklist with two extra items: jurisdiction for contract disputes (where does litigation happen if it comes to that), and tax and withholding implications. Otherwise the diligence is the same. Time zone differences are a working-style question, not a due-diligence question, and should be evaluated separately.
What if we are the smaller party negotiating with a much larger vendor?
Most of the 12-point checklist still applies, but expect more standardisation on their side. Their contract is harder to negotiate, but is usually more reliable. Their reference calls are easier to schedule because they have processes for it. Their sub-contracting is more transparent because they have to disclose it for compliance. The trade-off is they may have less flexibility on scope and price.
Should we use an RFP process?
For engagements over about $250k total contract value, yes. For smaller engagements, a structured shortlist plus the 12-point checklist plus reference calls usually produces better outcomes than an RFP, which tends to optimise for the vendor who writes the best proposals rather than the one who delivers the best work. RFPs also self-select against smaller vendors who do not have the overhead to respond to them, which is sometimes the wrong selection signal.
