The most useful way to evaluate a Web3 developer is to ask them to explain a decision they made, what it cost, and what they would do differently. Anyone can show you a project list. Very few people can tell you honestly why a specific choice was wrong.

I am going to write this as the criteria I would be measured against, including the parts where I do not score well yet. That seems more useful than a list of warnings with me conveniently exempt from all of them.

The five things worth checking

1. Can they explain a trade-off, including what it cost?

Listen for a specific decision and a specific consequence. "I chose to read one chain instead of five because supporting five shallowly would have produced answers nobody could trust" is a trade-off. "I use best practices" is not. The best answer includes something they gave up.

2. Can they show you something running?

A live URL and a public repository tell you more than any description. Open them. Check whether the live thing matches the claim. Check whether the repository has real history rather than a single commit. Check whether the failure states were built, not just the happy path.

3. Do they tell you when you do not need them?

This is the single strongest signal, and it is the easiest to test. Describe your situation and see whether they narrow it. If every conversation ends in a proposal, you are not being advised, you are being sold to. Someone who says "you should not build this yet" has just saved you more than their hourly rate.

4. How do they handle the failure paths?

Ask what happens when a transaction reverts, when a wallet rejects, when an API times out, and when a user does something unexpected. In Web3 this is not a detail. It is where products lose users, and where irreversible mistakes happen. A developer who has not thought about it will answer in generalities.

5. Do you own everything at the end?

Code, credentials, deployment, and documentation. Ask directly. If the answer involves them hosting it indefinitely, or their own API keys sitting in your production environment, or access you cannot revoke, you are renting your product rather than owning it.

Questions that reveal more than a portfolio

  • "Tell me about a decision you would reverse." A refusal to answer is an answer.
  • "What will this not do when you hand it over?" Anyone who claims nothing is hiding it.
  • "What is the riskiest part of this build, and how will we find out early?"
  • "Who writes the code?" Relevant for studios and agencies as much as individuals.
  • "What happens if you are unavailable for two weeks?"
  • "Which parts of this should not use AI?" A good answer distinguishes judgement from determinism.

Red flags

  • Tool lists instead of outcomes. Nobody's product ever got better because the developer knew Rust.
  • Guarantees about adoption, growth, or price. Not in anyone's control. A promise here tells you what you are dealing with.
  • Case studies you cannot verify. Especially in a domain where the work is often confidential. Ask what part of it they can substantiate.
  • Scope that never gets narrower. If every conversation adds work, the estimate is not an estimate.
  • No documented limitations. Every real build has them. A handover with nothing listed is a handover that has not been thought about.

What to ignore

Years of experience as a headline number. Tool and framework badges. Logo walls you cannot verify. Claimed metrics with no described measurement. None of it correlates reliably with whether someone can take a fuzzy problem and turn it into working software.

How I would score myself against this

Fair is fair, so here is the same assessment applied to me.

  • Evidence you can check: seven deployed personal projects, all with public demos and repositories, all labelled as founder-built rather than client work.
  • Written boundaries: every service page states what is outside scope, and every project lists its known limitations.
  • Clear nos: no audits, no guaranteed outcomes, no token or equity-only work, and I will say when a project needs a team instead of me.
  • Honest weakness: I am early. I have no client case studies yet, because I have not completed client engagements to write up. I would rather tell you that than invent them.
  • Honest weakness: I am one person. I cannot run several workstreams in parallel, and any project that needs that should go to a team.

If those weaknesses are disqualifying, the criteria above just saved us both a month. If they are not, the detail is on my profile page, and the trade-offs between hiring an individual and an agency are in Web3 agency versus freelancer.