Short answer: the single most reliable filter is verifiability. A real Web3 studio can hand you mainnet contract addresses, verified source code, a past audit report, and a founder who'll confirm they built the thing. A reseller can hand you screenshots. Everything below · the 12 questions, the red flags, the on-chain verification walkthrough · is a way of forcing that difference into the open before you wire a deposit. We're a studio ourselves, so read this as the checklist we'd want used on us: send us a brief and ask us every one of these.
Why hiring in Web3 is different
Hiring a normal software agency badly costs you money and time. Hiring a Web3 agency badly can cost you the treasury · because the deliverable isn't just an app, it's code that custodies value and keys that control it. The failure modes are worse too: unaudited contracts that get drained post-launch, studios that keep a mint key or multisig seat "for support," and template token contracts resold with your logo on top. That's why the vetting below leans so hard on three themes: provable shipped work, audit process, and key custody. Get honest answers on those three and most of the risk is gone.
The 12 questions to ask before you sign
Ask these in order. The early ones filter out resellers fast; the later ones shape the contract you'll actually sign.
| # | Question | What a good answer sounds like |
|---|---|---|
| 1 | What have you shipped to mainnet, and what are the contract addresses? | Addresses, immediately, without hedging. You'll verify them yourself below. |
| 2 | Who audits your code, and can I see a past report? | Named external firms or contest platforms, plus internal tooling (Slither, Echidna) run first. "We audit internally" alone is a red flag. |
| 3 | Who holds the deploy keys, owner roles, and multisig seats · during the build and after? | You as primary signer from day one; the studio rotates out at handover, and the rotation is scripted and auditable. |
| 4 | Who exactly will write my code? | Named senior engineers you can talk to · not a sales layer fronting an anonymous outsourced bench. |
| 5 | How do you quote · fixed, hourly, or retainer · and what happens when scope changes? | A written scope with a fixed quote, and a named change process. Vague retainers hide drift. |
| 6 | How is payment structured? | Milestones tied to working builds, final tranche at key handover. Never 70% upfront. |
| 7 | How often do I see a working build? | Weekly demo cuts you can click, not a 90-day silence ending in a big-bang reveal. |
| 8 | Is the code written for me, or adapted from a template? | Honesty. Standards-based building blocks (OpenZeppelin) are good; a resold fork sold as custom is not. Ask which is which. |
| 9 | What do I own at handover? | Everything: repos, deploy keys, owner addresses, third-party accounts, docs, design files. No lock-in, no exit conditions. |
| 10 | What happens when the audit finds issues? | Fixes included in scope, and a re-audit of meaningful changes · budgeted upfront, not billed as a surprise. |
| 11 | What's your realistic timeline · and what would make it slip? | A range with named risks. Anyone promising a full token launch in 7 days is skipping the audit. |
| 12 | What happens after launch? | A clear answer either way: optional retainer, documented handover, or both. "We'll figure it out" means unplanned dependency on them. |
None of these questions require you to be technical. They require the studio to be · and the pattern of answers tells you which kind of shop you're talking to. (For structuring the money side properly, see how to pay a Web3 development studio.)
Red flags that predict a bad ending
- A portfolio you can't verify. Screenshots, logos, and case studies with no contract addresses, no live products, and no named clients. If nothing is checkable, assume it's borrowed.
- Guaranteed hype timelines. "Token launch in 7 days, guaranteed listing" is physically possible only by skipping tokenomics, testing, and the audit · the three things that keep you alive.
- Audit hand-waving. No external audit relationships, "our seniors review everything," or a refusal to show any past report. Audit-later is audit-never.
- Large upfront payments. 50–70% before any code exists, with the rest "on delivery." You've just funded their runway, not your project.
- Key custody after handover. The studio stays on your multisig, keeps a mint or upgrade key, or owns the deployer address "for maintenance." That's not maintenance · that's control.
- Template resale as custom. Suspiciously low quotes usually mean a forked contract with your name find-and-replaced in. You inherit every bug of the original, plus new ones from the sloppy edit.
- A sales layer between you and the builders. If you can't talk to the person who'll write the code before signing, you won't be able to after either.
One flag deserves a conversation. Two or more · walk. There are enough studios that pass all seven for you not to gamble.
How to verify shipped contracts yourself (5 minutes, no coding)
This is the step almost nobody does, and it's the one that catches fake portfolios instantly.
- 1 · Get addresses. Ask for 2–3 mainnet contract addresses from past projects. Not repo links, not screenshots · addresses.
- 2 · Open them in a block explorer. Etherscan for Ethereum, Basescan for Base, Polygonscan, Solscan for Solana. Paste the address in.
- 3 · Check "Contract" → verified source. A green check means the source code is published and matches the deployed bytecode. Unverified contracts from a studio claiming transparency are a bad sign.
- 4 · Check the transaction history. Real products have organic activity over months. A contract with ten transactions from the same wallet is a demo, not a shipped product.
- 5 · Cross-check the client. Find the project's site or founder and confirm the studio actually built it. One LinkedIn message is enough · and studios with real clients will connect you happily.
If a studio's portfolio survives all five steps, you're already dealing with the top slice of the market.
Agency vs freelancer vs in-house · the honest matrix
A freelancer is right for small, sharply-scoped tasks · a contract review, a fix, a simple mint. The risk is concentration: one person is your builder, tester, and bus-factor. In-house is right when Web3 is the company and you can attract genuinely senior contract engineers · rare and expensive, but correct at scale. A studio is right when you need a full launch shipped · tokenomics, contracts, audit coordination, claim UI, ops · without hiring five specialists you'll only fully need for a quarter. Costs sit between the other two; the vetting above is how you make sure you're paying for builders, not a brochure. Whichever route you take, the audit and key-custody questions never change.
How we answer our own checklist
Fair's fair. Shipped work: live products with addresses and founders you can talk to are on our shipped page. Audits: internal review plus Slither/Echidna before any external pass, coordinated with firms from Trail of Bits and OpenZeppelin down to boutique reviewers depending on your value at risk · with re-audits budgeted for every meaningful change (what audits actually cost). Keys: Safe or Squads multisigs with you as primary signer from day one; we rotate out at handover and script the rotation. Quotes: fixed scope, fixed number, milestone payments. Builders: the person replying to your brief is the person writing your code. Send a brief and put us through the twelve questions · we enjoy them.
FAQ
How do I verify a Web3 studio's shipped work?
Ask for mainnet contract addresses and check them yourself on Etherscan or Solscan: verified source, real transaction history, dates that match the claims. Then confirm with the client that the studio built it. Hesitation to share addresses is itself an answer.
What are the biggest red flags?
Unverifiable portfolios, guaranteed 7-day launches, audit hand-waving, big upfront payments, the studio keeping keys or multisig seats after handover, and template forks resold as custom. Two or more · walk away.
Agency, freelancer, or in-house?
Freelancer for small scoped tasks, in-house when Web3 is your core business at scale, a studio when you need a full launch shipped without hiring a five-person team. The audit and key-custody questions apply to all three.
How should payment be structured?
Milestones tied to working, verifiable deliverables, with the final tranche at handover of keys, repos, and docs. Never a majority upfront.
Do I need to be technical to vet a studio?
No. Every check in this guide · the 12 questions, the red flags, the block-explorer walkthrough · can be run by a non-technical founder in an afternoon. The studio has to be technical; you just have to be systematic.