...

3 Common Mistakes When Building a web3 Platform

The most common mistakes that teams make when it comes to building a web3 platform.

Share

Intro

During the past year I’ve had to look at, consult for, put together a commercial proposal and/or been involved in the Product Definition of around 100 web3 projects and would like to share the most common mistakes that teams make when it comes to building a web3 platform.

Lack of Product Definition

Most, if not all, projects are successfully delivered when there’s a well defined scope, requirements and product definition in general. Some clients would want a quote produced from a pitch deck, mockup or google doc with a vague description and some bullet points.

When it comes to web3, or software development in general, the Product Definition phase of the project is perhaps the most critical. By skipping PD, there’s always surprises that end up with scope creep, blown-out budgets and delayed delivery. Spending time on User Journeys, defining (and prioritizing!) requirements, and having a complete set of User Stories (plus other techniques) will set the foundation of the platform.

Interestingly, it’s often the case that, while going through this phase, disagreements between project team members (usually founders) arise and, needless to say, it’s better to iron out things at the beginning instead of in the middle of the project.

Product Definition is a paid service that Labrys can provide to its clients and whilst most will tell you that they understand the importance of it, many opt not to pay for it, instead hoping to maximize their budget on direct development. In my experience, this does not save costs in the long run and only leads to more expensive mistakes during development.

Building the Platform Around a Token

I’ll start by saying that not every single web3 platform needs a token. And those platforms where a token is required, should spend a great deal of time defining the token economics (aka tokenomics).

Let’s see how bad tokenomics can cripple a project:

  • Lack of token utility – In order to justify the existence of a token, some projects force demand with use cases such as “buy my product/service with my $TOKEN” and then they get into this scenario:

 

In this scenario, the users looking to procure the platform’s product or service only need to obtain the token just so they can spend it (often right away) without needing to hold it, which means the token demand is temporary at best.

Another inefficient token use case is “Staking”. The original purpose of staking was to secure POS networks, validate blocks and be rewarded for doing so. These days, a lot of platforms have “staking programs” with the sole objective of reducing circulation, guaranteeing team and early investors the possibility of selling their tokens with less sell pressure. Good read on the topic here.

  • Unfair Token Distribution – Some teams issue a token (before having a platform) with distributions not only skewed in favor of the team and early investors but also badly designed Vest Schedules which typically generate the below price action:

 

 

While this might be good for early investors and founders, now you have a community pissed off and that will probably not only give the project bad marketing on social media but also not use the platform at all.

We recommend our clients to spend time defining their token economics with specialized teams, such as our partners at RMIT Blockchain Innovation Hub.

Here are some good resources for further reading on tokenomics:

To wrap this one up:

Building a bigger-than-needed platform

While it is important to have a product roadmap, some clients are tempted to include way too many features on their initial product release. Web3 is a highly experimental industry which moves at a neck-breaking speed and by wanting to build platforms with all the bells and whistles founders could end up burning a lot of money for a platform that might not end up finding product-market fit.

The best approach is to build either a Proof-of-Concept or a Minimum Viable Product in an Agile fashion and release it to the market to see what the reception is. Most platforms will require several iterations and some of them will end up pivoting to different use cases down the track.

Let’s define these concepts so everyone is on the same page:

POC: aims to demonstrate the feasibility or potential value of your idea or approach to validate it before committing significant resources to its development.

MVP: a cost-effective way to validate market demand and gather feedback on your product or service, it’s a great way to showcase your value proposition to target customers and improve chances of success.

 
Only then teams should focus on a fully fledged Production platform that is released at scale.

Conclusion

If you are part of a team building a web3 platform, put some consideration into these topics in order to maximize the chances of success of your product. Questions and feedback are always welcomed, feel free to reach out.

GET IN TOUCH

Drop us a line below and we’ll get back to you as soon as possible.

LABRYS HQ

Suite 1, Level 1/299 Coronation Dr Milton (Brisbane) QLD 4064
🇦🇺 Australia

Get exclusive updates and offers!

Seraphinite AcceleratorOptimized by Seraphinite Accelerator
Turns on site high speed to be attractive for people and search engines.