When considering working on a blockchain-based project, you need to think about some arguments that can really make you give up (or double down) on the whole blockchain thing.

1. Do you really need blockchain technology?

Blockchain technology is not a magic trick that will solve all problems and make every project great. It’s still very new, still in beta phase, if you will. You should consider using the blockchain tech, or any other distributed ledger (DLT) or consensus technology, only if nothing else can be used instead.

Currently, there are two good use cases for blockchain:

1. a decentralized, immutable database shared between different parties (companies, organizations);
2. a decentralized, public, immutable, open database for transferring value (e.g. altcoins and tokens) between different parties.

Most probably, every other use case would be better and cheaper served by a traditional, centralized database. Attaching the blockchain tech to a project only for the hype factor can be a good marketing strategy, but will most definitely backfire later on, during product development.

2. Bridge the competence gap by doing something easy first

Here’s one way of looking at the competence gap: it’s present every time you do something you haven’t done before. Every new project will require bridging this gap. The gap is smaller if the new project is similar to the ones you’ve completed before.

You can think about the competence gap in terms of technology, industry, clients, employees, subcontractors or market.

A project using new technology for a brand-new client in a new industry will have a bigger competence gap than a project using new technology for the same client in the same industry. If you’re developing blockchain software for the very first time, pick a project that’s easy. Choose the one where many aspects (people, market, industry etc.) are familiar and the only competence gap is the blockchain tech itself. It sounds obvious, but most ICOs out there are doing just the opposite.

3. It’s easier to teach someone smart how to do something new than not-so-smart, specialized people how to be smart

It’s always a good idea to work with smart people. One of the reasons is that smart people can learn new things relatively easily. If you already have a smart senior full stack developer on your team, it’ll be easier and less risky to teach them Solidity than to hire an unknown junior Solidity developer. The risk of bringing in someone new who might not hold a candle to the rest of the team can be greater than the cost of training one of your employees.

The new technology paradox

Also, there’s the following paradox: if no one in your company knows Solidity, how will you verify if the person you want to hire is qualified? Not to mention the fact that there are very few Solidity developers out there. The technology itself is very new, so it’s impossible to expect people to have years of experience writing smart contracts. This means junior developers are hard to find and seniors are as rare as unicorns.

4. Optimization: running the code can cost money

Applications running on a public blockchain platform (e.g. Ethereum) have to pay the network for computing power, memory, and storage using the platform’s cryptocurrency, which has a real-world, real-money value (as of May 27th, 2018, ETH is trading at $569).

This means that there’s a new layer of optimization that has to be taken into account when developing software, mainly, how much it will cost to run it. The same task and the same process can now be performed in a less or more expensive way. This layer is another competence gap that has to be bridged.

5. Socio-economic system

Every project that involves transferring value, coins, or tokens, also involves the creation of a completely new socioeconomic system. Rules and incentives embedded in the software influence the real-life behaviour of the users. Bitcoin miners spend a lot of money on hardware and use a lot of real-life resources, like electricity, because of the incentives provided by the Bitcoin protocol.

Designing software in this context is much more than designing a database. It requires you to understand economics, strategy, complex systems, social psychology and game theory.

And this is perhaps the biggest competence gap to bridge. Mainly because it’s usually not even recognized.