How to choose a web3 development company: a guide for founders

A good web3 development company tells you which parts of your product belong on a blockchain, builds those parts with security first, and hands over code, keys and documentation that you fully control. This guide is for founders and product owners who plan to hire an outside team for a Web3 product. It covers scoping, chain choice, team roles, the engagement steps, costs, contract terms and warning signs.

Scope the kind of Web3 product you are building

Web3 development services cover very different projects. Pick a firm that has built products in your category, because a strong general reputation does not replace that experience.

Some founders are not yet sure that the product needs a blockchain. The explainer on Web3 development and Web2 vs Web3 helps with that question before you talk to vendors. A short consulting engagement can also answer that question.

Choose the chain before the vendor

The chain sets the programming language, tools, wallets and audit firms. A firm that is strong in Solidity may have little experience with Rust programs on Solana, and the reverse is also common.

Also check where your users, liquidity and integration partners already are. A chain with good technology and none of your users on it is a poor choice.

What a competent web3 development firm looks like

A typical product needs the roles below, which one firm or several firms can cover.

• Smart contract engineers who write tests before features and know the standard libraries well.
• A security lead who reviews designs for economic attacks as well as code bugs.
• Front-end engineers who understand wallet connection, signing screens and transaction states.
• Backend or data engineers for indexers, APIs and monitoring.
• DevOps engineers with strict key management: deployer keys in hardware wallets and multisig wallets for admin roles.
• A product lead who rejects on-chain features that do not need to be on-chain.

A separate firm performs the independent security audit under a separate contract. A vendor that offers to "audit its own code" offers a code review, which is useful but does not replace an independent audit. The smart contract audit guide explains what a real audit includes.

The engagement, step by step

1. Paid discovery, one to three weeks. The firm writes the requirements, the on-chain and off-chain split, a threat model, the chain choice, an architecture document and a fixed estimate for the next phase. Pay for discovery separately, so you can take the document to another team.
2. Design and prototype. The firm defines contract interfaces, events and admin roles, and builds a clickable or testnet prototype.
3. Build. The team writes contracts with full test suites and builds the front end, indexer and backend in parallel. You get a testnet deployment to try each week.
4. Internal hardening. The team runs fuzzing and invariant tests, does a second internal review and freezes the code.
5. External audit and fixes. Book the auditor early. The team fixes the findings, and the auditor reviews the fixes.
6. Guarded launch. The team deploys to mainnet with deposit caps or allowlists, monitoring and a written incident plan.
7. Handover or retainer. The firm delivers documentation, transfers all admin rights to your multisig wallet and supports the product for an agreed period.

The web3 app development guide covers the stack behind steps 2 to 4.

Cost drivers for web3 development services

Hourly rates vary several times over by region and seniority. Estimate effort in team-weeks, then apply the rates from your quotes.

Four factors change the cost most:

• Novelty: a fork of a well-audited design costs less than new mechanics.
• The number of chains.
• Integrations with oracles and bridges.
• Compliance features such as KYC checks.

Audit cost grows with code size and complexity. Running costs continue after launch: RPC providers, indexing, monitoring, gas for sponsored transactions and maintenance.

Red flags

• The vendor promises "guaranteed" exchange listings, returns or token price support. Such promises often point to problems worse than bad engineering.
• The vendor deploys contracts from its own keys and keeps admin rights "for convenience".
• The repository has no test suite, or the tests cover only the expected path.
• The vendor pushes a token for a product that does not need one.
• The vendor will not give you repository access from the first day.
• The code copies contracts from other projects without credit and without regard to the scope of the original audit.
• The vendor's portfolio has items you cannot verify on-chain. Ask for contract addresses and check them on a block explorer.

Questions to ask a web3 development company

• Which of our features would you keep off-chain, and why?
• Walk us through the threat model for our design. What would an attacker try first?
• Show us contract addresses from past work and the audit reports for those contracts.
• Who will hold upgrade and admin rights at launch, and how will you transfer those rights to us?
• How do you handle oracle failures, chain reorganizations and RPC outages?
• What does your estimate leave out?

Contract terms to negotiate

The statement of work protects you as much as the vendor's skills do. Get these points in writing:

• IP assignment. All code, designs and documentation pass to your company on payment. Any vendor libraries reused in the product come with a permanent license to you.
• Ownership of accounts. The code lives in your organization's repository. Cloud and RPC accounts and domain names are in your company's name.
• Key handover. A dated checklist moves every privileged role (owner, upgrader, minter, pauser, treasury) to your multisig wallet. You can verify on-chain that the vendor's addresses no longer hold those roles.
• Audit fixes. The contract says who pays to fix audit findings and how many re-review rounds are included.
• Warranty. The vendor fixes bugs found during a set period after launch and commits to response times for critical incidents.
• Open-source licenses. Forked code under licenses such as BUSL or GPL carries obligations. The vendor lists every dependency and its license.

Build, fork or white-label

A fork of an audited open-source protocol is often faster and safer than new contracts, if you follow its license. Every change to the fork still needs review. A white-label product reaches the market quickly in standard categories. It also looks like its competitors, and you may not control its upgrades. A custom build suits mechanics that nobody has built before. The guide to blockchain development services compares these routes for projects outside Web3 as well.

Frequently asked questions