Estimating the cost of a blockchain project is pretty tricky, as there is generally not much experience in the field. Usually it is not estimated apriori because on the one hand there are a lot of unexpected technological challenges and on the other hand the requirements are unclear as well. For this reason usually there is no cost estimation at the beginning of a project but the project is delivered in an agile way starting with a proof of concept, continuing with a working prototype, which is followed by the fine tuning of both the requirements and the technological architecture.
Anyway, blockchain projects usually have the following factors to be considered, most of them based on the architectural requirements of the project:
- Smart contract development: key element of the architecture is the smart contract, developing such contracts is more or less resource intensive. Like in case of a solidity, Ethereum development of the code itself is not too much energy, however a lot of efforts have to be put into testing, quality assurance and formal verification as the contract will be deployed into a public immutable ledger.
- Blockchain infrastructure: at public blockchain platforms, the blockchain infrastructure both the live and the different test networks are usually configured. For consortium blockchains, the whole infrastructure has to be planned, configured and delivered, which might be a huge task. There are some initiatives however to speed up the infrastructure deployment of a consortium blockchain networks, like Azure blockchain from Microsoft or Chello project from Hyperledger
- Fronted or UI: Fronted and user interface is usually required for every blockchain application. It usually requires classical fronted development with javascript, HTML and CSS. There are experimental platforms however where you can speed up the fronted development. Like in Azure Blockchain Workbench, you can click together some of the UI elements, or in Hyperledger Fabric composer, where based on the business blockchain definition file, there is the possibility to automatically generate a basic user interface.
- Storage: If storage is required, the major question is if it is centralized or decentralized. If it is decentralized, like in IPFS or Swarm, usually the smart contract developers manage this part of the development as well. If it is a centralized storage, like a classical file system or an SQL DB, the integration must be implemented. There are already frameworks which can speed up some blockchain integration with existing storage systems, like Azure Blockhain from Microsoft.
- System integration: In enterprise blockchain application, exiting legacy systems, like databases, existing ledgers, authentication providers... should usually be integrated with the Blockchain. This can mean atomic swaps, or simply import - exports. Some enterprise blockchain systems already provide experimental services in this direction.
- Non-technical roles: usually some management roles should be considered as well in a Blockchain project, like a project manager if the project is getting more complex, a Blockchain consultant and requirement engineer to fine tune the business requirements.
