Does this price include the audits?

No, and you should assume audits are a separate budget of their own. For a protocol holding real deposits, external reviews and a bug bounty are a serious line item in their own right, and that is normal rather than a sign something has gone wrong. We build toward review — frozen commits, written specifications, invariant tests already in place — so the reviewers spend their time on your logic rather than on things a free tool would catch.

We have the contracts already and just need a front end. Is that cheaper?

Cheaper than a full build, yes, but it is not a website project and pricing it as one is where the budget goes wrong. A front end over live contracts has to handle token approvals and allowances, network switching, the full sequence of transaction states, RPC endpoints failing mid-flow, and surfacing a contract revert in language that stops a user from losing money. That is weeks of work, and we read your existing contracts before quoting because their design determines how much of it there is.

Why can you not just query the blockchain directly for our dashboard?

Because chains are built for writing and verifying, not for reporting. Asking a node for every event your protocol has emitted since launch is slow, expensive and unreliable at any real volume. The normal answer is an indexer such as The Graph that consumes events into a queryable form, and building that subgraph is a defined part of the work rather than an afterthought.

Can you fix a bug after launch?

Only in ways decided before launch. A deployed contract cannot be edited — a fix means a new deployment, a new address and a migration of state and users, which is a project of its own. This is why the upgradeability decision, the pause design and the emergency plan are all settled during specification, and why we launch with deposit caps rather than at full capacity.

What monitoring do we get?

Alerts on the conditions that matter for your specific protocol rather than generic uptime — unusual transaction sizes, invariants drifting, admin functions being called, oracle staleness, and liquidity moving abnormally. Those thresholds are defined with you during the build, wired into Tenderly alerts, and routed to a channel someone actually reads at night.

Why does the testnet phase take so long?

Because it is the only place where mistakes are free. The expensive losses in this field are not bugs inside one contract — they come from the interaction between two individually correct contracts, or from an external protocol's price being moved for a single block. Those only appear when the whole system is running together under adversarial pressure, and that takes weeks rather than days.

Blockchain & Web3

dApp and DeFi development

On-chain applications built the slow way — invariant testing, months of testnet, a capped launch, live monitoring and an emergency plan written before it is needed.

From: $6,000–$60,000
Typical time: 2–6 months
Usually bought by: Web3 startups

What this actually solves

If you are on this page, the contracts are probably not a feature of your business — they are the business. A lending market, an exchange, a yield product or a structured position is its code. There is no operations team quietly correcting things behind the scenes, no ledger to reconcile in the morning, and no way to reverse a transaction that should not have happened. Whatever the contracts permit is what the product does, permanently, to everyone who uses it.

That changes the economics of building it. Total value locked is treated as a success metric, and it is also the bounty on your protocol's head. The moment real deposits arrive, a global population of extremely capable people begins reading your code for a living, full time, with no deadline and a direct financial reward for finding one thing you missed. The tool that removes the last barrier to entry is a flash loan — an attacker does not need capital, only a way to borrow enormous size for a single transaction, move a price, extract the difference and repay inside the same block. Building for that audience is a different discipline from building an application, and it is why the timeline on this page looks long relative to its price.

How the build runs

Protocol specification, including the economics. Not just what the functions do, but what must always be true — solvency conditions, accounting invariants, who can do what, where prices come from and what happens when they are wrong or stale. Oracle design and upgradeability are decided here, in writing, because both are almost impossible to change later. Two to four weeks.
Contracts, with invariant testing from day one. Written against OpenZeppelin implementations, developed locally with Foundry, and tested with fuzzing and invariants rather than only example cases — properties like total obligations never exceeding backing, and no user being able to withdraw against another's balance, asserted across random sequences. Echidna is used where the property is worth attacking harder. Two engineers read the contracts independently. Four to ten weeks.
Front end and integration. The application layer over live contracts — wallet connection, network switching, approvals and allowances handled explicitly, the full transaction lifecycle from submitted through pending, replaced, reverted and confirmed, RPC failover, and contract errors translated into something a user can act on instead of a hex string. Three to six weeks, overlapping.
Indexing, monitoring and the emergency plan. A subgraph so your data is queryable and your dashboards do not hammer an RPC endpoint. Alerts on protocol-specific conditions rather than uptime. And a written emergency runbook naming who does what, in what order, within how long, including who is authorised to trigger a pause at three in the morning — agreed before launch, because it is not a document anyone can write during an incident. Two to three weeks.
Testnet at length, then a capped mainnet launch. Weeks of the full system running on a testnet under deliberate abuse, external security review, and a bug bounty before deposits open. Mainnet starts with deposit caps that rise on a written schedule tied to time and clean behaviour, not to enthusiasm. Four to eight weeks plus the review window.

The two habits that matter most here are not tools. Every contract is read independently by a second engineer who did not write it, and the deposit cap schedule is written down before launch so that raising it is a decision against a plan rather than a reaction to a good week.

What moves the price

How many contracts have to agree with each other. A single-purpose contract with a front end sits at the bottom of the range. A system of contracts sharing accounting, permissions and price assumptions sits at the top, because the expensive work is in the seams between them rather than inside any one file.

How many external protocols you integrate. Every oracle, router, lending market or bridge is a dependency whose behaviour under stress you now own — what your protocol does when that price goes stale, that pool empties or that contract pauses.

Whether the design is new or a fork. Adapting a widely deployed protocol is a different job from designing mechanics nobody has attacked yet, both to build and to review. The range is $6,000–$60,000 over 2–6 months and covers development only; audits, bounties and the ongoing monitoring budget sit outside it.

What usually goes wrong

A dApp request is quoted as a website. The contracts are finished and all that is left is a front end, so it gets priced like a website build. Then the real requirements arrive — approvals and allowances, chain switching, the full run of transaction states, an RPC endpoint that dies mid-flow, and the obligation to present a contract revert in a way that prevents a user losing money. It is a multi-week engineering job over live financial state, and treating it as a marketing site is how both the budget and the launch date break.

Each contract is tested alone and the system is never attacked as a whole. Every unit test passes because every contract is individually correct. The loss comes from the relationship between two of them, or from an external price being moved for a single block by borrowed capital. Unit tests cannot see either. Invariant tests across the whole system, a long adversarial testnet period and independent review are the only things that do.

The protocol opens at full capacity with no cap and no alerting. Deposits are uncapped from day one because the launch went well, monitoring is generic uptime checking, and there is no written answer to who pauses what and how fast. A protocol's riskiest weeks are its first ones, when the code is newest and the attention is highest. Caps that rise on a schedule, alerts tuned to your own invariants, and a runbook written in advance turn a potential total loss into a bounded one.

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.

Does this price include the audits?: No, and you should assume audits are a separate budget of their own. For a protocol holding real deposits, external reviews and a bug bounty are a serious line item in their own right, and that is normal rather than a sign something has gone wrong. We build toward review — frozen commits, written specifications, invariant tests already in place — so the reviewers spend their time on your logic rather than on things a free tool would catch.
We have the contracts already and just need a front end. Is that cheaper?: Cheaper than a full build, yes, but it is not a website project and pricing it as one is where the budget goes wrong. A front end over live contracts has to handle token approvals and allowances, network switching, the full sequence of transaction states, RPC endpoints failing mid-flow, and surfacing a contract revert in language that stops a user from losing money. That is weeks of work, and we read your existing contracts before quoting because their design determines how much of it there is.
Why can you not just query the blockchain directly for our dashboard?: Because chains are built for writing and verifying, not for reporting. Asking a node for every event your protocol has emitted since launch is slow, expensive and unreliable at any real volume. The normal answer is an indexer such as The Graph that consumes events into a queryable form, and building that subgraph is a defined part of the work rather than an afterthought.
Can you fix a bug after launch?: Only in ways decided before launch. A deployed contract cannot be edited — a fix means a new deployment, a new address and a migration of state and users, which is a project of its own. This is why the upgradeability decision, the pause design and the emergency plan are all settled during specification, and why we launch with deposit caps rather than at full capacity.
What monitoring do we get?: Alerts on the conditions that matter for your specific protocol rather than generic uptime — unusual transaction sizes, invariants drifting, admin functions being called, oracle staleness, and liquidity moving abnormally. Those thresholds are defined with you during the build, wired into Tenderly alerts, and routed to a channel someone actually reads at night.
Why does the testnet phase take so long?: Because it is the only place where mistakes are free. The expensive losses in this field are not bugs inside one contract — they come from the interaction between two individually correct contracts, or from an external protocol's price being moved for a single block. Those only appear when the whole system is running together under adversarial pressure, and that takes weeks rather than days.

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 dApp / DeFi development All Blockchain & Web3 services