Credentials answer the wrong question

What to look for in a technical partner before the first conversation.
By Vadim Zolotokrylin Vadim Zolotokrylin

Most founders evaluating a technical partner spend their time on the wrong question. They land on a partner's page, scan the project list, note the metrics, read the testimonials, and make a judgment about fit. That judgment is almost always about qualification — has this person shipped something like what I'm building?

Qualification matters. But it is not the decision you are actually making.

When you bring a technical partner into your founding team, you are making a relationship decision. This person will be in the room for the product calls that define your company's direction. They will make architecture choices your team will live with for years. They will push back on your instincts, and you will need to trust their judgment when they do. The question is not "have they shipped something similar?" The question is: would I trust this person when it matters?

The credentials trap

Most partner pages are built around the qualification question. Project history, metrics, testimonials, notable outcomes. This is a natural default — credentials are concrete and easy to present. But they tell you what someone has done, not who they are.

The founders who make the costliest mistakes in technical partnerships are not the ones who ignored credentials. They are the ones who used credentials as a proxy for fit. The track record was impressive. The projects were real. The numbers checked out. And six months in, the relationship was wrong in ways the résumé could not have predicted.

A technical partner is not a hire you evaluate on scope delivery. We have written about what the role actually requires in The technical co-founder you don't need to hire — the short version is that the value is in the judgment calls, not the output. Credentials tell you whether the output has been real. They do not tell you whether the judgment is right for your product.

The question worth asking

What you are actually evaluating is conviction — whether this person thinks the right way, cares about the right things, and will show up fully when the work is hard.

Conviction is harder to present than a project list. It requires a partner to articulate what they believe about building, what they have learned from the decisions that went wrong, what they stand for when scope needs to be cut or a difficult trade-off needs to be made. That clarity is what separates someone who has shipped things from someone you would trust to shape your product.

A sharp one-line articulation of why a partner builds — not their job title, not a list of past projects — tells you more about fit in ten seconds than a full credential list. If you cannot find that on the page, it is not because the page is too short. The clarity is not there.

Where credentials belong

This is not an argument against credentials. A strong body of work matters. It validates the conviction. It tells you whether the beliefs behind the work produced real outcomes.

But credentials earn their weight when they follow the conviction, not when they replace it. "I believe X. Here is what I built because of that belief." That sequence builds trust. The reverse — leading with the project list and attaching the conviction as an afterthought — reads like a résumé, and a résumé makes someone look like a contractor.

The founders we have worked with longest connected with how we think before they connected with what we have shipped. The work made the conversation real. But the conviction started it.

What to look for

When you are reading a technical partner's page, the credential list is easy to find. What is harder — and more important — is evidence that this person has thought hard about the right things.

Does their writing or their summary tell you something specific about how they approach building? Do they have a clear point of view on the problems your kind of company faces? Is there a coherent thread between what they say they believe and the work they have actually done?

The most useful first conversation with a technical partner is not a reference check. It is a test of how they think. Ask them about a technical decision they made that turned out to be wrong, and what they would do differently. Ask what they would not build in your situation, and why. Ask what they are still figuring out.

The founders who find the right partners are not the ones with the most rigorous credential review. They are the ones who ask the harder question first.

Have a suggestion? Edit this page