The big picture success of blockchain requires a transparent understanding of the costs of developing blockchain applications, or dApps, as well as analysis of tools that can reduce those costs in order to increase overall dApp development.
This case study presents a side-by-side analysis of the development costs for an iconic and important Web3 application* and xBacked, a substantially similar stablecoin application. We conducted our analysis by reviewing the projects’ respective GitHub code repositories and then reviewing our results in direct conversation with a member of each team that built these projects.
We conclude that the approximate cost to build the "M" application was $1M and the approximate cost to build the xBacked application was $135k. In other words, the xBacked application cost 86.5% less to build than the "M" application.
Additionally, this paper offers insights to help illuminate the barriers to Web3 development and some levers to lower those barriers, and data on developer salaries, which are a major input to total development costs. It concludes with thoughts on what all this means for blockchain protocol ecosystems and their growth aspirations as well as investors looking to grow their Web3 portfolios.
*We are currently working to get approval by this well-known Web3 application to use their name in this case study. For the rest of this case study we will refer to this application as the “M” application.
Why We Chose to Compare "M" and xBacked
Cost comparisons have value only when we are looking at two dApps that are substantially similar in what they do and how they are designed, which is why we chose to compare development costs for "M" and xBacked. While these dApps exist in different Layer-1 ecosystems, both provide a stablecoin that facilitates transactions on their respective L1 chains. Both dApps mint the stablecoin when collateral is entered into the smart contract, and both burn the stablecoin when the conditions of the smart contract are fulfilled (the stablecoins are returned and the collateral is claimed).
One difference between these two dApps is that "M" has a DAO and xBacked has not yet built its DAO. To remove this difference from our cost comparison, we only analyzed application costs. In other words, the total cost to build "M" does not include any of its DAO-related development costs.
Another important difference is that "M" was built in Solidity and xBacked was built in Reach.
Cost Comparison Findings
The following table compares the cost of development between xBacked and "M"DAO and shows how Reach was able to reduce the cost of development by over 85% when used to build an application that is very similar to "M"DAO.
The xBacked team built their application with fewer developers and only had to write a fraction of the code required to build "M". xBacked was built in 6 months, as compared to 10 months for "M", and at a total cost of $135,000 vs a total cost of $1,000,000 for "M". In short, xBacked was 8x less expensive than "M".
This cost comparison table uses the actual salary numbers shared with us by the respective teams. Further on in this paper, we will show broader research on developer salary costs to address any question as to whether the salary costs provided by "M" and xBacked are representative of the industry as a whole.
We are now going to more closely examine two major root causes for why web3 development is so costly.
Root Cause #1: Solidity Programming Constructs Add to Development Costs
DApp development in Solidity requires extensive low-level programming, whereas Reach allows developers to work at a higher level of abstraction. The following example illustrates this point: When a developer implements an API in Solidity, if the developer uses more than 16 variables at a time, then
Solidity will fail to compile the program and they will need to rewrite it. What’s worse is that this limit of 16 includes variables that are implicitly created behind the scenes of the compiler, so it is not even as easy as counting the number of variables in your code. Even FORTRAN, which was first released in 1957, did not even have this limitation.
Root Cause #2: The Shortage of Solidity Developers Drives Up Costs
There are many concrete technical reasons that explain why Web3 development is so challenging for developers to master. The net effect is that the ability to build elegant, sophisticated and safe applications in Solidity is a scarce skillset. There is a supply and demand mismatch in blockchain today, which drives up development costs.
This supply constraint is exacerbated by the difficulty a Web2 developer experiences in trying to become proficient in Solidity. To become a beginner Solidity developer takes up to 6 months and to safely build anything of value it usually requires much more experience. Anecdotally, recruiters tell us that they see the most demand for Solidity developers who have 6-12 years of engineering experience.
Developer Supply in Web3 vs Web2
We can refer to two widely circulated Web3 reports to help us define the current state of developer supply. A16Z’s State of Crypto 2022 report suggests there are about 7,500 monthly active developers. The most recent report from Electric Capital indicates that a total of 34,391 blockchain developers filed at least one line of code on Github in 2021.
Even individual companies have higher numbers of developers than the total global population of blockchain developers. JP Morgan has about 33,000 developers and Google has over 27,000.
Representative Developer Salary Data
As the salary data in our side-by-side cost comparison came from the companies themselves, readers may reasonably ask whether these numbers are idiosyncratic and not actually representative of costs across the industry. And if these numbers are not representative of the industry as a whole, then perhaps the cost savings for other dApps would be less dramatic than in the "M" vs xBacked example.
If we substitute these developer salary costs into the "M" vs xBacked example, we would wind up with a total cost to build "M" of $691,153 and a total cost to build xBacked of $172,115, or 25% of the cost to build "M". We propose that this represents the highly conservative calculation of the relative savings and can be thought of as one end of a savings range. In other words the savings from using Reach vs using Solidity, for an application of this sort, is between 75% and 86.5%.
Implications of the Cost Benefit of a Reach Integration for L1 Protocols & their Ecosystems
As of the date of this paper, Reach is usable with all EVM chains (Ethereum, Polygon, Avalanche, etc.) as well as Algorand and Conflux. Reach is architected to integrate with any L1 blockchain and will continue to add other integrations going forward, typically in partnership with each chain’s ecosystem fund. The consequences of the cost benefits of using Reach are numerous.
Reach offers blockchain ecosystem funds much greater impact because they are able to catalyze and support more projects at the same overall cost. For example, in April of 2022, the Ethereum Foundation allocated $19.6M to build out the Ethereum ecosystem. If the average web3 application development cost is around that of "M"DAO, that's a mere ~20 projects that are being funded to fruition. If the Foundation covered the development costs of Reach-built projects, at an average development cost of 150K, 130 projects (6.5x) could be funded.
The overall reduced risk profile of Reach applications compared to traditional web3 applications also means these iterations can happen faster if and when bugs are detected. The Ethereum foundation gives out small grants of up to $30k to help developers test and experiment with new project ideas. To put that in perspective, $30,000 is the 4-month cost of one of the Web3 developers that built xBacked and barely over a month's cost for a single competent Solidity developer.
Reach is the only platform in the market that allows for accessible entry and limitless development capabilities at a fraction of the cost and complexity of traditional blockchain development. By drastically reducing the cost of blockchain development Reach is lowering the cost of verification and the costs traditionally associated with experimentation in Web3 development. We believe that the next ten thousand Web3 developers will be Web2 engineers and development teams that transition to Web3 with the creativity, tools, and financial ability to build that first killer-DApp and that Reach will be at the forefront of the world’s transition to Web3 for all the data-backed reasons provided in this case study.
Shanthi Purushotham serves as Chief of Staff at Reach Platform
Methodology for our Developer Salary Data Research:
Full Stack Developer Salary Data
Solidity Developer Salary Data
We looked at the pooled salary data available for solidity developers at 8 publicly available, commonly used salary and job sites. We used the 75th percentile of these ranges because, as mentioned in footnote 11, an application like "M" required senior-level Solidity developers, and, based on conversations with recruiters, Solidity developers require 6-12 years of experience to be a competitive candidate at web3 companies. In instances where the 75th percentile was not provided, we took an average of the median or mean (whichever was available) and the high value of the given salary range.
This salary data has been documented in the following spreadsheet: https://docs.google.com/spreadsheets/d/1aSZVMnoLb_pTjEQB_n0NacdIbG3oY3m-zbr9Tgad6FQ/edit#gid=967796115