Do we actually need a smart contract for this?

Often not, and we would rather say so before quoting than six months into a build. A chain write happens on every node in the network and is kept forever, which is exactly why it is slower and costs more per write than an ordinary database. You are paying to remove the need for a trusted owner. If your system already has an owner everyone accepts — you, a regulator, a bank, a large buyer — a signed record with a public verification page usually does the same job faster, cheaper and privately. We will price both routes and tell you which one we would take.

Who holds the keys once the contract is live?

You do. Deployment is done from a wallet holding only what that deployment needs, and ownership is transferred to a Safe multisig that you control on the same day, with the transaction link written into the handover document. We do not remain the permanent owner of a contract we built for you, and we never send a private key to anyone by any channel.

Should the contract be upgradeable or immutable?

It depends on whether you are still learning what the product is. Immutable is simpler, cheaper and easier for your users to trust, but a number frozen at deployment stays frozen. Upgradeable buys you the right to change your mind, and costs you a proxy, storage layout discipline and an admin key that is now a permanent target. We decide this in writing during the spec, not after deployment when there is no longer a choice.

Is an audit included?

No. This is development, and our own security pass with Slither, fuzz tests and a second engineer reading the code cold is not the same claim as an independent audit. If the contract will hold anyone's money other than yours, budget for a separate review and let us build toward it — a frozen commit, written specification and tests already in place make an external review shorter and cheaper.

Who pays the gas fees?

You do, from your own wallet, and this is written into every scope we send. Network fees are set by network congestion rather than by us, so we give estimates and never a fixed figure. The same deployment costs more when the chain is congested than when it is quiet, and less again on an L2.

Can you just use one of the no-code contract generators instead?

We can read one for you, and sometimes that is the right call for something trivial. What we will not do is deploy code we have not read line by line on your behalf. Several generators produce contracts carrying owner powers that are not on the marketing page — a fee switch, a transfer pause, an address blacklist — and once that is on-chain under your name it looks to the outside world exactly like something built to trap buyers.

Blockchain & Web3

Smart contract development

Solidity contracts specified function by function, tested harder than they are written, and handed over with ownership already sitting on your multisig.

From: $2,000–$30,000
Typical time: 3–10 weeks
Usually bought by: Web3 startups

What this actually solves

You have a commercial promise that other people need to believe without having to believe you. Investors want proof that the founding team's allocation is genuinely locked for three years, and an email saying so convinces nobody. A marketplace wants to hold a buyer's money between order and delivery without becoming the party everyone sues when it goes wrong. A game studio wants items to belong to players rather than to a server it might one day switch off. In every one of those cases the thing being bought is not code. It is a promise rewritten in a form that runs by itself and that nobody, not even you, can quietly amend later.

That property is genuinely useful and it is not free. A write to an ordinary database happens once on one machine and costs so little you stop measuring it. A write to a public chain happens on every node in the network and is kept permanently, which is precisely why it is slower and more expensive per write. The cost is not a flaw in the technology; it is what you are buying. So the first useful thing anyone can do for you is check whether you need it at all. If there is already an authority in your system that everyone accepts, the chain is not adding anything you are not already getting for less. When it genuinely is the right answer, everything below is what the work actually involves, and none of it is optional, because a bug in a deployed contract is not a Friday-night fix. The money does not come back.

How the build runs

Specification, function by function. We write down what each function does, what it deliberately does not do, and — separately and in a numbered list — every power the owner keeps. Who can withdraw. Who can pause. Who can upgrade. The chain choice is made here with the reason recorded, and the clause putting network gas fees on your wallet goes into the scope at the same time. Three to five days.
Local development and tests. Contracts are written against OpenZeppelin's audited base implementations and developed on a local chain with Foundry and anvil, where the money is worthless and the state can be reset at any time. The working measure we hold ourselves to is that the test file is longer than the contract — a 200-line contract with an 80-line test has not been tested, it has been reassured. Fuzz tests push random amounts and timings through it, and invariants assert the things that must never be false, such as total claimable rewards never exceeding the pool that was actually funded. One to three weeks.
Our own security pass. Slither is run and every finding is answered in writing, including the ones we deliberately leave alone and why. A second engineer reads the contract cold, without the first one explaining it. This step exists so that an external reviewer's report is about your protocol's real logic rather than a list of findings a free tool would have caught. Three to five days.
Testnet deployment and a rehearsal you run. The contract goes to Sepolia or Base Sepolia, gets verified, and then you drive it yourself from your own wallet — mint, transfer, claim, and deliberately do the wrong thing. This is the step that is easiest to skip and the one that saves the most money, because the design changes people ask for after using something are cheap here and impossible after mainnet. Three to seven days.
Mainnet deployment and handover. The day runs off a written runbook with every command in order, prepared in advance. Deployment comes from a wallet holding only what the deployment needs. Ownership moves to your Safe multisig the same day. Every constructor parameter is read back off the chain and compared against what was sent, the contract is verified on the explorer, and we watch it for two days. One to two days.

The handover is the verified contract link, source, tests, ABI, deployment record, and one page titled what the owner of this contract can do — every owner-only function listed with a plain sentence on what harm its misuse could cause your users. That page takes about an hour to write and it consistently earns its keep. You read it and ask us to remove powers you did not realise you had, which produces a better product; we catch our own design mistakes while writing it; and if anyone ever asks why the contract works the way it does, the answer exists in writing with a date on it.

What moves the price

How much money the contract will end up holding. A vesting contract that only ever holds tokens you funded yourself is a different risk from a staking pool holding deposits from strangers who will read the code looking for a way in. The second one needs more testing, more review and more caution, and it costs more for that reason alone.

How many contracts have to agree with each other. A single ERC-20 with a vesting schedule sits at the bottom of the range. A staking system with a reward accountant, a treasury and a token that all reference one another sits at the top, because most of the work is in the seams rather than in any one file.

Upgradeable or immutable. Upgradeability is not a checkbox. It brings a proxy pattern, storage layout rules that constrain every future change, and an admin key that has to be governed for the life of the product. The range is $2,000–$30,000 over 3–10 weeks, and this decision moves a project within it more than anything else.

What usually goes wrong

Ownership is left on the wallet that deployed it. The contract goes live, works perfectly, and its owner is a browser extension on a developer's laptop — for months. Then, when the relationship ends, the private key gets sent over WhatsApp so you can take over, and now it exists on two phones, two chat backups and a cloud drive. Both halves of that are avoidable. Ownership transfers to your multisig on deployment day, and a private key is never transmitted to anyone.

A number that needed to change was frozen in the constructor. A week after launch the price has to come down, or a cap has to move, and there is no setter for it. The only remaining options are deploying a new contract — new address, new verification, new listings, and a split between people who used the old one and people who use the new one — or doing nothing. The fix is in the specification, not afterwards: we ask which values might realistically need to change after launch, build setters for exactly those, and list each one in the owner-powers page, because every setter is also somebody's power over your users.

Reward arithmetic that assumes a well-behaved token and a bottomless pool. Staking contracts are where the quiet, expensive mistakes live. A token that takes a fee on transfer or rebases its balances will silently break accounting written for a plain ERC-20. Rewards computed per second round, and rounding in the wrong direction across thousands of claims drains a pool that arithmetic said was sufficient. And nobody specifies what happens when the reward pool empties mid-period until a user is standing in front of a claim that cannot pay. These are asked and answered during the spec, then pinned down with invariant tests, because they are not visible in a demo.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Do we actually need a smart contract for this?: Often not, and we would rather say so before quoting than six months into a build. A chain write happens on every node in the network and is kept forever, which is exactly why it is slower and costs more per write than an ordinary database. You are paying to remove the need for a trusted owner. If your system already has an owner everyone accepts — you, a regulator, a bank, a large buyer — a signed record with a public verification page usually does the same job faster, cheaper and privately. We will price both routes and tell you which one we would take.
Who holds the keys once the contract is live?: You do. Deployment is done from a wallet holding only what that deployment needs, and ownership is transferred to a Safe multisig that you control on the same day, with the transaction link written into the handover document. We do not remain the permanent owner of a contract we built for you, and we never send a private key to anyone by any channel.
Should the contract be upgradeable or immutable?: It depends on whether you are still learning what the product is. Immutable is simpler, cheaper and easier for your users to trust, but a number frozen at deployment stays frozen. Upgradeable buys you the right to change your mind, and costs you a proxy, storage layout discipline and an admin key that is now a permanent target. We decide this in writing during the spec, not after deployment when there is no longer a choice.
Is an audit included?: No. This is development, and our own security pass with Slither, fuzz tests and a second engineer reading the code cold is not the same claim as an independent audit. If the contract will hold anyone's money other than yours, budget for a separate review and let us build toward it — a frozen commit, written specification and tests already in place make an external review shorter and cheaper.
Who pays the gas fees?: You do, from your own wallet, and this is written into every scope we send. Network fees are set by network congestion rather than by us, so we give estimates and never a fixed figure. The same deployment costs more when the chain is congested than when it is quiet, and less again on an L2.
Can you just use one of the no-code contract generators instead?: We can read one for you, and sometimes that is the right call for something trivial. What we will not do is deploy code we have not read line by line on your behalf. Several generators produce contracts carrying owner powers that are not on the marketing page — a fee switch, a transfer pause, an address blacklist — and once that is on-chain under your name it looks to the outside world exactly like something built to trap buyers.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Smart contract development All Blockchain & Web3 services