How to hire a vetted development squad (without relying on the portfolio alone)

Hiring a vetted development squad means looking past what the team says about itself. A portfolio, curated references, and five-star reviews are self-reported signals — easy to dress up because the people showing them control the narrative. Verifiable signals are a different category: real code history, on-time delivery measured over time, client diversity, and disputes resolved with evidence. Those don't depend on anyone writing them in the squad's favor — they either exist or they don't.

Why isn't the portfolio and reviews enough?

The incentive to embellish a reputation is real, and it's been measured. A study by Michael Luca (Harvard Business School, 2011) on Yelp reviews found that a one-star increase in a business's rating can lift revenue by 5% to 9% — the kind of economic impact that explains why so many service providers, not just restaurants, have an incentive to inflate their online reputation. The US FTC ended up formally banning purchased, incentivized, and AI-fabricated reviews through a federal rule in 2024, precisely because the problem had scaled enough to require regulation.

None of this means the portfolio or references are useless — they're a fine starting point. The problem is treating them as sufficient proof. A well-presented case study doesn't tell you whether that squad delivers on time consistently, how many different clients it actually worked with, or what happened the last time something went wrong.

What signals are actually hard to fake?

A handful of signals don't depend on the squad's sales narrative because they're generated as a byproduct of actually doing the work:

• Real code history on GitHub — commits with authorship and dates, not a screenshot of the finished project.
• On-time delivery measured over time, not self-reported on a sales call.
• Client diversity — whether the squad delivered with different companies or depends on a single relationship that might not repeat.
• Disputes and how they were resolved, with the underlying scope and progress evidence available — not just the final outcome.

What questions should you ask before signing?

Beyond the signals you can audit independently, there are concrete questions that separate a squad that can explain how it works from one that only knows how to sell itself:

• How do they run the process — are there sprints, regular check-ins, defined testing, or “you'll see once we start”?
• Does code go through review before merging, with pull requests and a second set of eyes, or does one person write it unchecked?
• What's the ratio of management to engineering? If there are more people coordinating than coding, you're paying for coordination overhead, not technical capacity.
• Does the intellectual property of the code explicitly belong to the hiring company, in writing, or does the contract say something vague like “per local law”?
• What happens after delivery — is there agreed post-launch support, or does the squad hand over the code and disappear?

What if the squad can't answer these questions precisely?

A vague answer about security, about the testing process, or about who owns the code doesn't improve after the contract is signed — it gets worse, because there's no longer an incentive to clarify it. How a squad answers during evaluation is, in practice, the best sample available of how it will communicate during the project.

How Zenit solves this structurally — without relying on a sales call

Instead of asking the company to manually audit each squad's history, Zenit builds that verification into the infrastructure itself. Every milestone gets released through SafePay against acceptance criteria signed in advance, so on-time delivery gets recorded, not self-reported.

ZenitRank cross-references those signals — code, milestones, client diversity, disputes — into a score that updates on its own, one the squad can't edit.

And before it gets to that point, Kaizen — Zenit's discovery engine — has already understood the project in depth, so the match doesn't depend on a well-rehearsed sales pitch but on each squad's actual track record against comparable projects.

The framework above works for evaluating any development squad, whether it's on Zenit or not: separate what's said from what can be verified. The difference is how easy or hard that verification actually is for you — and that's where it pays off to choose the right infrastructure, not just the right vendor.