If you are starting to plan a blockchain development project, you have already concluded there are strong arguments why decentralised digital ledger technology is the right choice for your use case. Or could be.
But you might not have planned or managed a blockchain development project before. There is a lot in common with planning any other software development process – but also key differences.
If you are aware of those specifics and are in a position to manage them, blockchain development projects are as easy or difficult to plan and execute as any other software development.
But if you start a project blind to the unique requirements of blockchain development, you will run into trouble.
This blog is an overview of the key technical and business considerations to be aware of and core decisions to make planning a Web3 project. It won’t help take those decisions but the most important first step to successful planning
The number of blockchain development projects is rising
Blockchain technology’s unique combination of qualities, like decentralisation, immutability and cryptography, make it a potentially optimal solution for a wide variety of use cases across sectors. It also allows for new use cases; cryptocurrencies are the obvious example but other forms of Decentralised Finance (DeFi) and NFTs (which are not just cartoon monkey pictures) are others.
The breadth of technical challenges that blockchain solutions have the potential to improve, or make possible, means there is a lot of blockchain development happening. But it is also still a nascent technology – when is the last time you personally used a blockchain-based application that wasn’t a cryptocurrency exchange or wallet?
What makes blockchain development different? What do you need to know?
Blockchain’s unique characteristics and still relative immaturity as a technology have consequences. Anyone approaching a blockchain development project for the first time needs to be aware of:
- Blockchain development introduces new and different decisions at the planning stage of the Software Development Life Cycle. You need to know the questions that need to be asked – and be able to competently answer them.
- Blockchain development teams do not benefit from the same maturity of ecosystem as web developers eg. dev communities, code repositories and tooling. That makes their jobs more difficult – they are still pioneers and have to figure out and do more for themselves. It also makes blockchain development a less efficient and error-prone process than developing software with more mature technologies – with which almost everything has been done, and publicly documented, before. Less efficient development inevitably means more expensive development.
- There are fewer experienced senior blockchain developers than there are for more mature technologies like the core commercial web development stacks. And demand for experienced blockchain developers is growing quicker than supply is. That makes blockchain developers hard to recruit. And expensive. Yes, all software developers are hard to recruit and expensive. But that difficulty, and expense, is magnified when it comes to blockchain and Web3 recruitment.
- The combination of the previous two considerations means it is almost always more expensive to develop a blockchain solution than to take an alternative approach using popular, established commercial software development technologies. If your use case is only possible using blockchain technology – it will be expensive to build.
You should make sure you fully understand the lower and upper range of the costs you could incur developing and then running your blockchain solution. And make sure you are in a position to manage them well – and finance them.
I won’t go into exhaustive detail on each of these points of difference to be aware of in blockchain dev projects – the goal here is to highlight key considerations so you can avoid the kind of surprises that can become problematic.
Or even potentially derail a project.
But if you prepare yourself to be able to make these decisions and set up your project with these realities in mind, you will approach your blockchain project in a position of strength.
Blockchain development decisions – the core questions you need to answer
The SDLC of a blockchain development project has the same phases as any other SDLC, from planning and design through development, testing, deployment and maintenance. However, especially in the planning and design stage, there are different questions to answer.
The main decisions you will have to be in a position to make informed calls on are:
Choice of consensus mechanism
Proof-of-work and proof-of-stake are the main choices but there are also more niche alternatives including Byzantine fault-tolerant (bft), proof-of-authority (poa) and directed acyclic graph (dag).
Do you need your own crypto token?
Blockchain technology is tightly linked to cryptocurrencies because they were its first use case. A public blockchain needs cryptocurrencies to run because there practically needs to be a financial incentive for nodes to participate in the P2P network that verifies transactions.
Tokens operate like cryptocurrencies but are associated with software like dApps built on top of blockchains like Ethereum.
But unlike public blockchains, private blockchains or dApps built on top of blockchains don’t need their own native cryptocurrency or token to operate. The crypto aspect can be abstracted away.
Avoiding forcing users to use cryptocurrencies or tokens to access a dApp can make the process much more accessible and user-friendly while retaining the technological strengths of blockchain. Going tokenless also neatly sidesteps some of the legal and trust issues that come with them.
It very much depends on the nature of your project but one of the first big questions you should be ready to answer is if you need or want your own tokens or native coins. Define the needs of your system, and where a utility token might be useful or necessary.
If it’s not, it is probably better to avoid issuing a token or adding the complication of its use to the user experience.
Successful dApps including OpenBazaar and Mastodon are tokenless.
Choice of blockchain platform – or to build your own
In the vast majority of circumstances, it will not make sense to build your own proprietary blockchain from scratch. That would be a very significant undertaking – especially implementing the core engine and establishing the network of miners and nodes needed for a fast, secure P2P network.
You would usually only consider building a blockchain from scratch if you need a fully custom, private, and permissioned blockchain.
The following article on SpringerOpen is a deep dive case study on a blockchain-based energy trading system with characteristics that necessitated the development of a proprietary blockchain – Implementing a blockchain from scratch: why, how, and what we learned.
In the majority of circumstances, you will be developing your blockchain project on top of one of the most established and widely used smart contracts platforms, like:
Ethereum – the most popular blockchain platform for protocol and dApp development due to its wide, established usage and mature (in the context of blockchain development) ecosystem.
Hyperledger Fabric (Fabric) – the most used enterprise blockchain platform, Fabric is backed by IBM and other technology giants. Modular architecture allows for pluggable components like consensus algorithms that make the development process more efficient.
One big plus of Fabric is that its smart contracts, which it calls “chaincodes”, can be programmed in the established web development languages and frameworks Java, Go and Node.js, which many developers already know.
Solana – most popular for exchange systems and games. It is lower cost to use than Ethereum and faster but less flexible and, at least for now, doesn’t have as rich a development ecosystem.
Polygon – a sidechain rather than a fully independent blockchain platform, Polygon is an Ethereum scaling platform. Its advantages are higher speed and lower fees. Those come at the cost of weaker security.
Outside of these popular options, there are also other choices of blockchain such as TRON, EOS, NEO and BNB Chain.
For a more extensive list on popular blockchain platforms and their pros and cons, check out our blog post on blockchain platforms for smart contract development.
Warning – a less commercially popular blockchain platform may offer technical advantages at the cost of commercial viability
You should keep in mind that it will be harder to find blockchain and Web3 developers with experience building on less commercially popular platforms. The same can be said of the tech talent resource you would need to maintain, and potentially scale, to build your own custom blockchain.
More niche established blockchains also have less extensive and mature ecosystems.
Your choice of blockchain platform, and decisions on the rest of your architecture and tech stack, should take into account similar commercial considerations as other software development projects.
Commercial web development projects usually opt for a mainstream stack (like MEAN or MERN), despite sometimes strong technical arguments in favour of a more niche choice popular with developers – like SolidJS.
Why? Because there is a predictable supply of the recruitable tech talent needed to build, maintain and scale projects. And they benefit from the most mature ecosystems in web development, from tooling and frameworks to large and active open source communities.
For most commercial blockchain development projects there will be a strong argument to stick to Ethereum Virtual Machine (EVM)-compatible chains.
The EVM executes smart contracts and dApps code and EVM compatibility allows for the use of most of the same dev tools (the most developed ecosystem in blockchain development) as would be used to build a dApp directly on Ethereum.
For example, the BNB Chain, Fabric and Polygon are EVM-compatible. Solana isn’t and that means projects that choose to build on Solana will be harder to hire for.
Permissioned or permissionless blockchain?
You will also have to decide whether you want your blockchain project to be permissionless (public blockchain) or permissioned (private blockchain). Permissionless networks are completely open and allow for varying levels of user anonymity.
If you need or want to control access to your blockchain, you will need to build it as permissioned. You can still set up a private blockchain network on a public blockchain like Ethereum – you don’t need to build your own.
Blockchain nodes – build and run your own or use a node provider?
As a general rule, you will want to avoid dealing directly with nodes as part of a blockchain development project if you have a choice. Just as you wouldn’t want to build your own browser for a web app or for it to interact directly with a CPU.
A blockchain node is an open-source, cross-platform runtime that stores a complete copy of the distributed ledger and allows developers to create services. Nodes also allow any user of a blockchain to view the entire transaction history of blockchain.
Launching a node used to be the only way to connect to a blockchain. However, setting up, running and maintaining blockchain nodes is technically demanding, time-consuming and expensive.
Thankfully, there is now a good choice of specialist node providers that offer blockchain nodes-as-a-service.
Node providers offer an out-of-the-box way to access the information on a blockchain without having to run your own node. Instead of sending requests to a local node you have set up, you send them over the internet to a provider offering an identical API that is running fully-synced, up-to-date nodes available 24/7.
Most Web3 developers and projects don’t need their own nodes. It will only be advisable if you have very specific requirements around:
- Privacy and security – for the same heightened compliance and security reasons as some companies may avoid public clouds, some way not want their transactions being processed by shared hardware. But like some public cloud companies offer private clouds, some node providers offer dedicated nodes.
- Autonomy – no reliance on third parties and need to comply with their rules and regulations.
- Optimal decentralisation – no reliance on a centralised infrastructure provider.
- Customisation – full control of hardware setup and configuration can optimise performance for specific Web3 use cases.
You will have to take decisions on whether to run your own nodes or use a node provider. If the latter, you will have to choose which is the best fit for your project. Node providers differ from each other on points including:
- Blockchains supported
- Price
- Speed
- Developer tools
- Enhanced APIs
Some of the most popular node providers are Alchemy, Moralis, Infura and Quicknode. There are others and new entrants to the market can be expected.
Web3 APIs
Web3 apps, or dApps, query and write new data to the self-contained database of a blockchain via Web3 APIs, mirroring the use of APIs in traditional apps – which allow the front end, back end and databases to communicate with each other.
The fact that the database and back end are held on a blockchain in dApps requires the use of specialist Web3 APIs for processes including smart contract management, key management, the generation of addresses and keys and smart asset lifecycle management.
You can, and may sometimes have to, design and build your own Web3 APIs, especially if you are using your own nodes or have specific requirements. However, you can leverage out-of-the-box Web3 APIs from specialist providers. All major node providers also offer corresponding APIs.
Among the most established Web3 API providers are:
- Covalent
- Ankr
- QuickNode
- The Graph
- Bitquery
- Alchemy
- Biconomy
- Moralis
Forming your blockchain development team – tech stack choices
Your choice of core tech stack should be decided by a blockchain software architect with the experience to make informed decisions that take into consideration your:
- Use case
- Planned and possible future functionalities
- Performance requirements
- Security requirements
- Desired level of decentralisation
- Need for scalability
- Token requirements
- Business plan
- Availability of tech talent
- Budget
In blockchain development, programming languages, libraries and frameworks are used to programme the smart contracts that power your dApp’s functionality and the user interface.
Below is a summary of the most common tech stack requirements for blockchain development teams across front end and back end roles.
Blockchain front end development is almost the same as traditional development
Developing the user interface, or front end, of blockchain-powered dApps is no different from doing the same for a traditional application. That part is the same.
That gives you the freedom to choose a front end tech stack based on the same considerations as you normally would – the requirements of the app (eg. JS frameworks if dynamic content will be served) if existing in-house resources, availability of talent, future-proofed etc.
In most cases, you will probably opt for a commercially mainstream front end framework, for the same reasons as you normally would – you already have the talent with that tech stack in-house or it’s relatively convenient to put in place, either via direct recruitment or through an IT outsourcing partner or software development agency.
One difference between traditional Web2 and Web3 front end stacks is libraries like Ethers.js and Web3.js that are used to interact with blockchain data.
Smart contract programming – the tech stacks you need will vary with your blockchain platform choice
Source: Alchemy
The back end of you dApp is the blockchain, which hosts your data and the smart contracts that provide your functionalities. You will need back end developers with specialist Web3 and blockchain tech stacks to programme your smart contracts and to connect the front end to the blockchain nodes via Web3 APIs.
If you are using Ethereum or another EVM-compatible blockchain or sidechain, you will most likely need blockchain developers with experience in Solidity (Ethereum’s native programming language) and other smart contracts programming solutions like Remix and Hardhat, the JavaScript development environment for Ethereum software.
However, if you are using Solana, your back end team will need to be able to programme the smart contracts in Rust. Anchor is a Non-EVM development environment (like Hardhat) that lowers the barriers to Rust development of smart contracts on Solana.
Other programming languages that can be used for smart contract programming include Vyper, Yul, Cairo and Move.
Source: chain.link
Python, Java, C++, Go and Simplicity, a new high-level blockchain language built specifically for developing and reading smart contracts are other languages many blockchain development projects require in their team’s tech stack.
Staffing blockchain development projects – developer recruitment choices and considerations
Let’s start with what is often the key consideration to blockchain development project planning – Web3 developers are expensive. How expensive will depend on factors including:
- The needs and complexity of your project
- The tech stack(s) you are recruiting for
- Remote vs in-office presence
- Domestic vs international recruitment policy
- Employees vs contractors vs IT outsourcing
- Project duration
But whatever the conditions you offer and whatever your staffing strategy, you should expect to pay considerably more in salary or rates for experienced Web3 developers than web(2) developers.
That’s illustrated by talent.com data that puts the median annual salary for a senior Web3 developer at $160,000.
Compared to $115,000 for a senior web developer.
The relative inefficiency of blockchain development that comes from its less developed ecosystem also increases costs. Even an experienced development team will have more to work out and build from scratch compared to a comparable Web2 development project.
Source: Talent.com
But on the presumption you have the budget in place to fund the staffing needs of your Web3/blockchain project, a deficit of senior tech talent means it can still be difficult to actually recruit the specialists you need to build your dApp.
You have various choices to staff a blockchain development project:
- Locally recruited in-house employees working in your office or to a hybrid model
- Remote (national or international) recruitment of full-time employees
- IT outsourcing – different models from simple staffing (recruitment and payroll) with you managing the actual development process, to full service delivery including product planning, architecture, development and maintenance.
A relative shortage of Web3 talent in developed markets like North America and Western Europe means more would-be employers than employees or contractors in these regions.
As well as pushing up costs that also means targeted recruits can have multiple offers – often from the biggest names in tech, which have been sucking up available Web3 developer in recent years.
For startups, companies without a big name or those developing projects that are not seen by developers as exciting for one reason or another, recruiting Web3 developers locally can be a major headache. Even national recruitment can prove difficult to impossible.
If you do plan to recruit experienced Web3 developers locally or nationally in a developed economy, it is advisable to validate any presumptions you will be able to within your preferred or obligatory project timelines.
Our U.S.-based blockchain development client Ajna, a DeFi startup, came to us after months of frustrations trying to recruit Web3 talent in-house and locally had put their project dangerously behind schedule.
We were able to ramp up their team from 2 to 6 Web3 developers in 2 months by recruiting in Eastern Europe – Poland and Ukraine.
You can read the fascinating background story of 2 of that 4-strong team augmentation here- Andrii and Dmitro – blockchain bros born a year to the day apart
With the staffing of Web3 projects the most common point of difficulty, it is a critical element of a blockchain development process to get right – preferably from the beginning.
Think carefully about your needs, including:
- The size and makeup of the development team needed to build your project to your preferred timeline.
- The cost of maintaining that team long term
- The length of the development project to launch and then subsequent maintenance and iteration. You may need different resources at different stages of the SDLC and need to scale your team up and down.
Project planning is never perfect – but you need to make sure you get enough right
Project planning is never perfect. Which is why project planning worth its salt will build in elasticity in the expectation that some things won’t go according to plan. Blockchain development project planning follows that same logic.
But project planners do need to get enough right if the project is to be realised successfully. Even in an agile development project where much is discovered and adapted along the way based on user and market feedback, there are still things that need to be understood going in.
Things like:
- The raw ingredients and resources that need to go into a project
- The approximate costs of the different resources required
- Optimistic and worst-case scenario ranges for the quantity and quality of resources that may be required
- An idea of how sourceable and affordable those resources will be
You should now have a good overview of the core decisions you will need to make in preparation for and during a blockchain/Web3 development project. And the resources you will require to make those decisions and execute your project.
K&C is a Munich-based nearshore IT outsourcing provider with experience across a portfolio of blockchain and Web3 development projects. We offer IT outsourcing models from simple staffing to full delivery management from project planning to execution.
If your current or upcoming blockchain project could benefit from our experience and services, please get in touch.