If your goal is to build a new protocol, start from the end goal—internet-scale protocol like DNS, HTTP, SMTP—and work backwards.
A protocol is only as good as the number of independent and thriving clients, applications and businesses on it. A protocol with a lot of users but one dominant client is just an app with open APIs (for the time being). Practical alternative clients—not theoretical—matter for exit with interoperability.
Developers care far more about addressable quality daily active users (qDAUs) more than tech stack. A protocol with a lot of quality qDAUs and slightly worse technology will likely attract more developers than a protocol with better technology but few qDAUs. Quality defined as not bots or accounts that sign up and immediately churn (creating a ghost town effect).
Users don’t use protocols, they use apps. So if your goal is to build a protocol, you should build the initial app that’s high quality enough to earn the attention of enough qDAUs that developers start finding building on the protocol interesting.
Lastly, it’s easy for people to fall into the Field of Dreams fallacy for protocols — “if you build it, they will come”. Can’t expect others to spend the time and effort to build high quality products if you’re not willing to do it yourself.
First published on October 14, 2022
