My focused Web3 product builds start at $6,000 and typically run three to eight weeks. A single defined capability, such as an AI agent or one integration, starts at $2,500 and runs one to two weeks. A discovery sprint that decides what to build starts at $750 and runs three to seven days.

I am not going to quote an industry average, because I cannot verify one and I would rather give you numbers I stand behind. What I can do is tell you exactly which decisions move the price, so you can work out where your own project lands before you talk to anyone.

The published numbers

  • Product and technical discovery: from $750, three to seven days. You get a written direction instead of a build.
  • AI agent or Web3 integration sprint: from $2,500, one to two weeks. One defined capability, tested and handed over.
  • Focused dApp or product build: from $6,000, three to eight weeks. Frontend, backend, integrations, deployment, handover.
  • Embedded product engineering: from $2,000 per month, for teams that need ongoing capacity rather than a one-off build.

Those are starting points rather than fixed quotes. Final scope, timeline, integrations, and price are confirmed after a fit conversation, and the full breakdown is on the pricing page.

What actually moves the number

Not how impressive the idea is. Four things decide what a build costs, and all four are decisions rather than accidents.

1. How much happens on-chain

On-chain state is expensive in every sense. Every write costs the user money, takes time to settle, and cannot be undone. Moving a piece of logic on-chain is sometimes essential and sometimes a decision inherited from a document nobody questioned. It is the single largest swing factor in a Web3 build.

2. How many chains and integrations

A second network is not an API key swap. It brings different data shapes, different fee behaviour, and different user expectations. I built WalletLens across five EVM networks and OrderFlow on one, and the difference in effort was not marginal. Each third-party API is the same story: a new thing that can fail, a new rate limit, a new set of edge cases.

3. How much of the product is in version one

This is where most budgets go. Onboarding, accounts, billing, admin surfaces, notification preferences, and settings are usually the difference between a focused build and a long one. None of them are the reason someone came to your product, and most of them can wait.

4. How much judgement the AI is doing

An AI feature is cheap when it summarises or classifies. It gets expensive when it makes decisions, because decisions need boundaries, escalation, and testing against adversarial input. A useful rule: if a deterministic rule would do the job, use the rule. It is cheaper, faster, and it does not drift.

What makes an MVP cost more than expected

  • Two chains in version one. Almost always scope, rarely necessity.
  • Custom design work. Interface clarity is not optional. A bespoke visual identity is, and it is a separate budget.
  • A security review. If your contracts hold real value, they need a dedicated auditor. That is not something I sell, and it is not something to fold into a build budget at the end. See whether you need a smart contract audit.
  • Scope changes mid-build. Not the small adjustments, which are normal. The new requirement that changes the shape of the product. It gets scoped and priced when it arrives, which is what stops a four week build quietly becoming a six month one.
  • Ongoing maintenance. Real cost, often forgotten. Integrations break, prompts drift, and upstream APIs change. My default is to agree maintenance separately after the build rather than hide it in the build price.

Ways to spend less without getting less

Three options, in order of how often I recommend them.

  1. Buy discovery first. It is the cheapest engagement and it is the one that prevents the expensive mistake. If it concludes you should build less, it has paid for itself several times over.
  2. Prove one capability before building the product. A $2,500 integration sprint that tests the riskiest part of the idea can tell you more than a $6,000 build that assumes it works.
  3. Cut chains, not failure states. The temptation when budget tightens is to skip error handling. That is the worst possible thing to cut, because it is exactly what real users encounter, and a build that hides failures teaches you the wrong lesson faster.

What the number should not include

A guarantee of adoption, growth, or product-market fit. Anyone pricing that in is either lying or about to disappoint you. What you are buying is a working product, built to an agreed scope, with the limitations written down. The scope reasoning behind those builds is in how to scope a Web3 MVP before spending money.