Field notes / Project planning
What changes the cost of a Web3 project?
A useful estimate starts with what you need to launch. Here is how to turn an idea into a scope a development team can price and explain.
Start with one complete journey.
“Build a dApp” can describe very different jobs. A simple interface around existing contracts is not the same scope as a new protocol with its own accounting, permissions and integrations. A single headline price hides those differences.
Write down what someone should be able to do from start to finish. For a raffle, that could mean finding a draw, connecting a wallet, entering and checking the result. Include what happens when a step is unavailable or a transaction fails. That gives a team something concrete to estimate.
The decisions that change the work.
The quality of the starting material matters too. Working code, current documentation and a clear decision maker reduce uncertainty. An inherited codebase may need investigation before a reliable implementation estimate is possible.
Existing or new contracts
Integrating a documented contract is a different task from designing and testing new product rules.
Number of product flows
Every distinct user role, screen and transaction adds design, implementation and testing work.
External integrations
Wallets, data services and other protocols introduce dependencies that need investigation and testing.
Review requirements
Independent audits, specialist reviews and time to address findings need their own budget and place in the schedule.
Keep the whole launch in the budget.
Ask what an estimate includes. Product design, development, testing, deployment and handover are different activities. A quote that covers only contract implementation will leave other work to your team.
Separate one-time project work from recurring costs. Hosting, infrastructure, third-party services, monitoring and maintenance continue after release. Transaction fees depend on how the product is used. An external audit is also separate unless it is explicitly included.
- Discovery and an agreed product specification
- Contract, frontend and backend implementation
- Testing and independent review where needed
- Launch preparation and documentation
- Ongoing infrastructure and maintenance
Compare the same deliverables.
Two quotes are only comparable if they cover the same work. Ask each team to describe the user journeys, integrations, review steps and handover they have included. Check who owns the source code and who is responsible for operation after launch.
Look for stated assumptions. If a quote assumes one chain, one user role and existing contracts, a later decision to add more can change the estimate. Agree how changes will be discussed and priced before they happen.
A brief you can write today.
You do not need a long specification to start. A few clear answers can make the first conversation much more useful.
- Who is the product for, and what should they accomplish?
- What is essential for the first release?
- What code, designs or contracts already exist?
- Which integrations or chains are required?
- What review or operational requirements are already known?
- Is there a fixed deadline or a budget range to work within?
We scope before quoting. Share what you know and we can identify what needs a decision, what needs investigation and what can be estimated now.
Let’s talk
Talk through your scope
Tell us about your idea, how far you’ve got
and what you need help with. A few lines is a good start.