How to choose a Web3 development company: a 2026 checklist

To choose a Web3 development company, check three things before price: contracts they have actually shipped to mainnet (you can verify these on a block explorer), a security process you can describe back to them in your own words, and a contract that hands you the code, the deploy keys and the admin roles. A team that passes those three checks and fits your chain and budget is usually a safe bet. A team that fails any of them is not, however cheap it is.

We sit on the vendor side of this conversation, so read the rest with that in mind. This is the checklist we would want a founder to run on us.

Decide what you are buying before you shortlist

"Web3 development" covers very different jobs. A studio that builds great NFT mint sites may have never written a liquidation engine, and a DeFi protocol shop may have no interest in your consumer onboarding flow. Write one paragraph on what you need, then match it to the skills below.

If you are not sure which chain or language you need, sort that out first, or make it the first paid deliverable. A team that is good at one ecosystem will tend to recommend it, so it helps to have your own view before the sales calls.

Verify shipped work, not slides

Web3 has one advantage over most outsourcing. A lot of the evidence is public and permanent. Use it.

1. Ask for contract addresses. For any case study that involves smart contracts, ask which addresses they deployed. Open them on the relevant explorer. Is the source verified? Is it still in use? Who holds the admin role today?
2. Read the audit reports. Audit firms publish reports that name the codebase and usually the commit. Look at the findings and at how the team responded. A report with a dozen medium findings that were all fixed and re-reviewed tells you more than a clean report on a 200-line token.
3. Look at the code. Ask for a public repo or a read-only walkthrough of a private one. You are looking for tests, CI, a readable README and commit history that shows real people working over time.
4. Talk to a past client. One call with a founder they worked with is worth more than ten testimonials. Ask what went wrong and how the team handled it.
5. Check the people. Who will actually work on your project? Agencies sometimes sell with senior engineers and staff with juniors. Get names, and ask whether they are employees or subcontractors.

Don't skip the people check. In the Solidity Developer Survey 2025, half of all respondents had two years or less of Solidity experience. So "our team knows Solidity" tells you very little. Ask how many people on your project have shipped contracts that hold real money.

Questions to ask on the first call

Good teams answer these quickly and specifically.

• "Walk me through how a contract goes from first commit to mainnet at your company." You want to hear about specs, unit and fuzz tests, invariant tests, internal review, external audit, testnet deployment, a deployment script, and multisig ownership. Our Web3 software development process post describes what that path should look like.
• "Who holds the keys during development, and when do they move to us?" The right answer is that admin roles sit with a multisig you control from day one, or move there at a defined point before launch.
• "What would you not build for us?" Experienced teams push back. If nothing in your scope worries them, they have not read it closely.
• "Which audit firms have reviewed your code, and can I see the reports?"
• "What do you use for monitoring after launch?" This one quietly tests whether they are current. OpenZeppelin, for example, kept hosted Defender running only until July 1, 2026 and moved users to its open source Relayer and Monitor. A team still pitching hosted Defender has not looked at its own stack lately.
• "How do you handle a critical bug found after launch?" Look for a pause mechanism with clear limits, an incident runbook, a bug bounty and, ideally, familiarity with the SEAL Safe Harbor framework, which typically sets a whitehat bounty of 10% of recovered funds capped at $1 million.
• "What happens if we need to change direction halfway through?" This tells you how the contract and the team handle scope changes.

Judge the security process more than the portfolio

The biggest losses rarely come from exotic compiler tricks. Chainalysis data reported by The Block puts 2025 crypto theft at over $3.41 billion, with the Bybit hack alone around 44% of it. In that case attackers tampered with the Safe{Wallet} interface so signers approved a transaction that upgraded Bybit's wallet contract to a malicious implementation. That is a signing and operations failure, and no amount of Solidity skill would have stopped it. On the contract side, the OWASP Smart Contract Top 10 for 2026 ranks access control first and business logic second, ahead of reentrancy.

So ask about the boring parts:

• How are admin roles split, and which actions go through a timelock?
• Do they write invariant tests for the core accounting, or only unit tests?
• Who reviews code internally before it goes to auditors?
• How do they store deployer keys? Hardware wallets? A shared laptop?
• Do they recommend a bug bounty, and on which platform? Immunefi's standard for critical bugs scales rewards at 10% of funds at risk, so a team should be able to explain how that would work for your TVL.

If you want to understand what audits cost against what they prevent, read our smart contract security ROI breakdown.

Red flags

Any one of these is a reason to slow down. Two or more and we would walk away.

• They cannot give you a single mainnet contract address.
• They plan to deploy with an EOA they control and "transfer later", with no date.
• They propose writing your token, AMM or lending logic from scratch when an audited library or a well-known fork would do.
• No tests in the repos they show you, or tests that only cover the happy path.
• They promise an audit "included" and cannot name the auditor.
• They want payment mostly in your token, before launch. This can be fine as a small part of a deal. As the main payment, it ties their incentive to the token price, not to the quality of the code.
• They guarantee a launch date before discovery.
• Their contract keeps the IP until a final milestone, or licenses it to you instead of assigning it.
• They cannot explain the licence of the code they plan to fork. Some popular DeFi code ships under the Business Source License, which restricts production use until a change date.

Engagement models compared

There is no right model in general, only a right model for how well defined your scope is.

A pattern that works well is a short paid discovery phase first, with a fixed fee and a fixed output: a technical spec, an architecture, a risk list and an estimate. You keep the documents whether or not you continue. It costs you a few weeks and it is the cheapest way to see how a team thinks. If you go the team extension route, our hiring strategy guide covers when it beats hiring in-house, and our team extension service shows how we run it.

For budget ranges by product type, see our Web3 development costs guide. Don't pick the cheapest of three quotes without asking why it is cheapest. Usually one quote skipped invariant testing, audit remediation or post-launch support.

Contract terms that protect you

The contract matters more in Web3 than in regular software because some mistakes cannot be undone once deployed. Get a lawyer who has seen software development agreements, and make sure these points are covered.

IP assignment. All code, designs and documentation are assigned to your company, ideally as work is paid for rather than at the end. "License" is not the same as "assignment".

Third-party and open source code. The vendor lists every library and fork they use, with its licence. MIT and Apache libraries such as OpenZeppelin's are fine. Anything under a source-available licence needs a decision from you, in writing.

Repositories and accounts. Repos live in your GitHub organization from the first commit. Cloud, RPC, indexer and domain accounts are in your name. Make the vendor a member, not the owner.

Keys and admin roles. The contract states who holds deployer keys, when admin roles move to your multisig, and that the vendor keeps no privileged role after handover. This is the clause founders forget, and it is the one that hurts most.

Audit remediation. Fixing audit findings is in scope, and so is a re-review. Otherwise you pay twice.

Warranty and support. A bug-fix window after launch (30 to 90 days is our planning estimate for a reasonable range), plus an optional support retainer with response times for incidents.

Termination. You can stop at the end of any phase, pay for work done, and receive everything produced so far.

Non-solicitation, both ways. Reasonable and time-limited. Some contracts also allow you to hire team members after a fee, which is useful if you plan to bring development in-house.

A simple way to score your shortlist

Score each finalist from 1 to 5 on these, and weight them. Our planning weights are below. Change them if your product is unusual.

Price is not on the list on purpose. Compare it after you have scored, among the teams that passed. A 20% saving on development is small next to one bad deployment.

FAQ

How much does it cost to hire a Web3 development company?

It depends on scope more than on the vendor. A token or simple contract set is a small project. A DeFi protocol with audits is a large one. The cost guide linked above has ranges by product type. Get at least two quotes after a written spec.

Should I hire freelancers or a Web3 development agency?

Freelancers can work for a well-scoped contract with an experienced CTO overseeing them. For a full product with contracts, frontend, indexing and design, an agency or studio gives you one accountable team and continuity if someone leaves.

What should be in a smart contract development agreement?

IP assignment, a list of third-party code and licences, repos and accounts in your name, a key and admin role handover clause, audit remediation in scope, a warranty period and termination by phase.

How do I check a blockchain developer's past work?

Ask for deployed contract addresses and check them on a block explorer: verified source, real usage and current admin. Then read any audit reports for that code and talk to one past client.

Is the audit usually included in the development price?

Usually not, and it shouldn't be. You want the auditor contracted by you, so they work for you and not for the team being reviewed. The development team should include fixing findings in their scope.

Can a Web3 development company help with tokenomics and launch?

Some can. Check whether that work is done by people with launch experience or is an add-on. Tokenomics and legal work often sit with specialists, and the development team should coordinate with them.

Talk to us

If you are comparing Web3 development companies, put us through this checklist. Ask us for contract addresses, audit reports and the names of the people who would work with you, and start with a fixed-scope discovery phase if you want to see how we think before committing. Our case studies are a good place to begin. Get in touch here.