Hiring a smart contract developer: a checklist before you sign

Short answer

Before you sign, confirm the developer has shipped on your chain, writes thorough automated tests, and has a clear plan for upgradeability and admin keys. For anything that will hold real value, budget for an independent security audit by a firm that didn’t write the code. Deployed contracts are hard or impossible to change, so mistakes are expensive and public.

Updated November 3, 2026By Velvy.ai6 min read

Why is hiring a smart contract developer different?

Most software can be patched after launch. A smart contract is public code that often holds money, runs exactly as written, and can be called by anyone, including attackers who read it line by line. Depending on the chain and how it was deployed, it may be impossible to change at all.

That changes what you are hiring for. Speed matters less than discipline: careful design, adversarial testing, minimal complexity, and a deployment and key-management plan that holds up when something goes wrong.

Which chain should you build on: EVM, Solana, Sui or TON?

Choose the chain for your users, liquidity and ecosystem first, then hire for it. Skills don’t transfer automatically: each platform has its own language, state model and classes of bugs.

Smart contract platforms compared: EVM chains, Solana, Sui and TON
Criteria	EVM chains	Solana	Sui	TON
Languages	Solidity, sometimes Vyper.	Rust, usually with the Anchor framework.	Move, in Sui’s object-based form.	Tolk, Tact or FunC.
State model	Each contract keeps its own storage.	Programs are stateless; state lives in accounts passed into each call.	Assets are objects with explicit owners.	Contracts are actors that talk through asynchronous messages.
Upgrades	Deployed code is immutable; upgrades use proxy patterns.	Upgradeable by default through an upgrade authority, which can be revoked.	Package upgrades are controlled by an upgrade capability and its policy.	Only if the contract includes code to replace itself.
Test tooling	Foundry or Hardhat, with fuzzing and mainnet-fork tests.	Anchor’s test tooling and a local validator.	Move unit tests built into the Sui CLI.	Blueprint and its local sandbox emulator.
Typical fit	DeFi, tokens and NFTs that need broad wallet and protocol support.	High-throughput apps where low fees and speed matter.	Games and digital assets that benefit from Move’s asset safety.	Apps distributed through Telegram.
Bugs to probe	Reentrancy, access control, oracle manipulation.	Missing account-ownership and signer checks.	Object ownership and capability leaks.	Bounced messages and partly failed multi-message flows.

Swipe the table sideways to see every column →

If you are undecided, a good developer will walk you through the trade-offs for your product, including which chain they would not use for it, and why.

What testing should you expect?

Ask to see the test suite from a previous project. For anything holding value, expect:

Unit tests for every function, including the paths that should fail: unauthorized callers, bad inputs, edge-case amounts.
Fuzz or property-based tests, where the chain’s tooling supports them, that throw random inputs at the contract and check that invariants, such as “total supply equals the sum of balances,” always hold.
Integration or fork tests against real deployed protocols and realistic state, not just mocks.
Static analysis in CI, with findings reviewed rather than ignored.
A testnet deployment that rehearses the exact mainnet deployment and configuration steps.

A coverage percentage on its own tells you little. Ask which invariants they test and which attacks they considered.

Do you need an independent security audit?

For anything that will hold real value, yes. An audit is a time-boxed expert review of a specific version of the code, by people who did not write it. The developer who built the contract is the worst-placed person to find its blind spots, however good they are.

Plan for it from the start. Book the audit early and leave time in the schedule to fix what it finds.
Freeze the code first. The audit covers a specific commit. Later changes need review too.
Expect findings. The auditor should re-review the fixes before you deploy.
Deploy what was audited. Verify that the deployed code matches the audited version.
Keep going after launch. A public bug bounty and on-chain monitoring catch what an audit misses.

An audit reduces risk; it does not guarantee safety. Be wary of anyone who presents one as a certificate that the code is secure. Ethereum.org’s smart contract security guide is a good, vendor-neutral overview of the practices to expect.

Should the contract be upgradeable?

It is a trade-off between flexibility and trust. An upgradeable contract lets you fix bugs and add features, but whoever controls upgrades can change the rules, and your users have to trust them. An immutable contract is easier for users to trust and harder for you to fix.

Ask the developer to explain, for your project:

Which parts need to change over time, and which should be fixed forever.
Which upgrade mechanism they will use on your chain, and the risks it brings, such as storage-layout collisions with EVM proxies.
Who can trigger an upgrade, whether a timelock gives users notice, and whether upgrades can be switched off permanently later.

Ethereum.org’s guide to upgrading smart contracts covers the main EVM patterns and their trade-offs.

Who holds the keys?

Admin keys are where many projects fail, even with well-written contracts. Settle these before deployment:

Multisig for admin roles
No single private key can upgrade, pause or drain the contract.
Timelocks on sensitive actions
A delay on upgrades and parameter changes gives users and your team time to react.
Separate deployer and admin keys
The deployer hands its roles to your multisig and keeps no privileges afterwards.
Keys never in code or chat
Private keys and seed phrases stay out of repositories, CI logs and messages; signers use hardware wallets.
A written emergency plan
Who can pause the contract, how signers are reached quickly, and what happens next.
Every role transferred to you
At handoff, every admin role sits with addresses your organization controls.

What are the red flags when hiring a smart contract developer?

Asks for your seed phrase or private keys. A developer never needs them.
Says an audit isn’t needed for a contract that will hold real value.
No tests to show, or “testing” that means clicking through a testnet by hand.
Wants to keep admin keys after launch, or proposes a single-key admin for an upgradeable contract.
Copy-pasted forks they can’t explain. Reusing well-reviewed libraries is good; pasting code they don’t understand is not.
Promises the code is “unhackable,” or guarantees outcomes nobody can guarantee.
Pressure to skip testnet and go straight to mainnet.

How Velvy works

How Velvy works on smart contract projects.

Velvy is a software studio. We build smart contracts and the apps around them with founder-grade full-stack delivery, and a build comes back as a working, tested, observable system, not a demo.

We don’t perform security audits. For any contract that will hold value, we recommend an independent audit by a firm that didn’t write the code, planned for from day one.

Projects start with paid discovery instead of unpaid test projects, then run on one of our engagement models.

Book an intro call

Engagement models

MVP Build: 5–8 weeks
Fractional engineering: 2–3 days a week
Hourly: Milestone-based

Related services

Common questions

Asked by buyers, answered here.

Something else on your mind? Ask us directly at hello@velvy.ai.

How do I choose between EVM, Solana, Sui and TON?

Start from your users and ecosystem: where the wallets, liquidity, partners and distribution you need already are. Then weigh language maturity, tooling and the availability of auditors for that chain. Hire a developer who has shipped on the chain you choose; the skills overlap less than people expect.

Does every smart contract need an audit?

Anything that will hold or move real value should have an independent audit before mainnet. For a low-stakes experiment or an internal prototype, thorough tests and a peer review may be enough, but treat that as a deliberate risk decision, not a default.

Can the developer who wrote the contract audit it?

Self-review is part of good development, but it isn’t an audit. An audit’s value comes from independent reviewers who didn’t write the code and have no stake in shipping it on time.

Is an audited contract guaranteed to be safe?

No. An audit is a time-boxed review of one version of the code. It lowers risk; it doesn’t remove it. Combine it with strong tests, careful key management, monitoring and a bug bounty after launch.

Should smart contracts be upgradeable?

It depends on your users and your product. Upgradeability lets you fix bugs but asks users to trust whoever controls upgrades. A common approach is to keep upgrades behind a multisig and a timelock, and to restrict or remove them once the system is stable.

What should I own at the end of a smart contract project?

The source code and tests in your repository, the deployment scripts, verified source on the block explorer where the chain supports it, documentation of every admin role, and every admin role transferred to addresses your organization controls.